EDITURA FUNDA łIEI ACADEMICE “DANUBIUS” GALA ȚI 2008 C S I D Proiectarea sistemelor informatice de gestiune Cuprins E 2 Cuprins Cuprins… [630261]

UNIVERSITATEA “DANUBIUS” GALA łI
DEPARTAMENTUL DE STUDII PENTRU ÎNV óà MÂNT LA
DISTAN łĂ

GABRIELA VÎRLAN
Cristina Maria Enache
Cristina Gabriela Zamfir

Proiectarea sistemelor
informatice de gestiune

EDITURA FUNDA łIEI ACADEMICE “DANUBIUS” GALA ȚI
2008
C

S

I

D

Proiectarea sistemelor informatice de gestiune
Cuprins E 2 Cuprins
Cuprins …………………………………….. …………………………………………… …………………………………………… ……. 2
Capitolul 1 No Țiuni fundamentale……………………………. …………………………………………… ………………. 4
1.1. NoŃiunea de informaŃie…………………… …………………………………………… ………………………………………..4
1.2. NoŃiunea de sistem………………………. …………………………………………… …………………………………………..5
1.3. NoŃiunea de sistem cibernetic…………….. …………………………………………… …………………………………..6
1.4. NoŃiunea de sistem informaŃional………….. …………………………………………… ………………………………..7
1.5. NoŃiunea de sistem informatic …………….. …………………………………………… ………………………………….9
Capitolul 2 Sisteme informatice ……………….. …………………………………………… …………………………….13
2.1. Categorii de produse software…………….. …………………………………………… ……………………………….. 13
2.1.1. Procesoarele de text…………………… …………………………………………… ………………………………………. 14
2.1.2. Programe de calcul tabelar……………… …………………………………………… ………………………………….. 15
2.1.3. Software pentru baze de date……………. …………………………………………… ……………………………… 16
2.1.4. Programe de prezentare…………………. …………………………………………… ………………………………….. 17
2.1.5. Programe de lucru pe Internet…………… …………………………………………… ………………………………. 18
2.2. Alte tipuri de produse software…………… …………………………………………… ………………………………. 19
2.2.1. Programe utilitare …………………….. …………………………………………… ………………………………………… 19
2.2.2. Pachete integrate ……………………… …………………………………………… ………………………………………..20
2.2.3. Proiectare asistată pe calculator……….. …………………………………………… ………………………………20
2.2.4. Programe de gestionare a documetelor Ți de birou ………………………………….. ……………………20
2.2.5. Shareware Ți public domain……………………………… …………………………………………… ……………….. 21
2.3. Clasificarea sistemelor informatice……….. …………………………………………… ……………………………..22
Curs 3 Stadiul actual și tendinŃele dezvoltării sis temelor informatice………………………….. 27
3.1. EvoluŃia sistemelor informaŃionale în cadrul f irmelor…………………………………….. ………………….30
3.2. Sisteme integrate pentru firme ……………. …………………………………………… ……………………………… 31
3.2.1. Enterprise Resource Planning ……………. …………………………………………… ………………………………..32
3.2.2. Supply Chain Management………………… …………………………………………… …………………………………33
3.2.3. Customer Relationship Management………… …………………………………………… …………………………34
3.2.4. Business Intelligence ………………….. …………………………………………… ………………………………………35
3.3. Sistemul informatic de gestiune…………… …………………………………………… ……………………………….36
Capitolul 4 Metodologii de realizare a sistemelor i nformatice………………………………….. …….37
4.1. Etape în proiectarea unui sistem informatic … …………………………………………… ……………………….38
4.2. Modele utilizate în proiectarea unui sistem in formatic ……………………………………. ……………….40
4.3. Metodologii de analiză Ți proiectare a sistemelor informatice ………….. ……………………………. 41
4.3.1. Metodologii de analiză sistemică ………… …………………………………………… ……………………………… 41
4.3.2. Metodologii de analiză structurate ………. …………………………………………… ……………………………45
Capitolul 5 – Analiza Ți proiectarea orientată obiecte ……………….. ……………………………………50
5.1. Concepte utilizate în tehnologia orientată obi ect………………………………………… …………………….50
5.2. Limbajul unificat de modelare î UML ……….. …………………………………………… …………………………..58
5.2.1. Evolu Ția limbajului UML ……………………………. …………………………………………… ………………………..59
5.2.2. No Țiuni generale despre UML……………………… …………………………………………… …………………….63
5.2.3. Concepte UML………………………….. …………………………………………… ………………………………………….66
5.2.4. Diagramele UML………………………… …………………………………………… ……………………………………….. 71

Proiectarea sistemelor informatice de gestiune
Cuprins E 3 Capitolul 6 Metode de proiectare a bazelor de date . …………………………………………… …………..84
6.1. Proiectarea bazelor de date utilizând regulile de business ………………………………… ……………..86
BIBLIOGRAFIE ………………………………… …………………………………………… ……………………………………..87

Proiectarea sistemelor informatice de gestiune
Noșiuni fundamentale E 4 Capitolul 1
Noșiuni fundamentale
În informatică, la fel ca în orice știin Ńă se opereaz ă cu no Ńiuni, concepte, m ărimi primare și derivate.
Aceste concepte, no Ńiuni sunt corelate prin legi pentru descrierea dife ritelor fenomene și aplica Ńii care
îi sunt proprii. Determinarea și definirea acestor concepte și legi în mod riguros și clar, permite și
ușureaz ă abordarea, în Ńelegerea și însu șirea informaticii ca știin Ńă și ca meserie.

Legea care se are în vedere înainte de toate, este legea potrivit c ăreia calitatea informa Ńiilor de ie șire
dintr-un sistem este în func Ńie de calitatea informa Ńiilor la intrarea în sistem.

Informatica a ap ărut ca știin Ńă în al cincilea deceniu al secolului nostru, în str âns ă leg ătur ă cu apari Ńia
și dezvoltarea calculatoarelor electronice. Din aces t motiv informatica a fost un timp denumit ă „ știin Ńa
calculatoarelor ".
1.1. NoŃiunea de informaŃie
Rezolvarea corespunz ătoare a problemelor din ce în ce mai complexe, în t oate activit ăŃile vie Ńii sociale
și economice, reclam ă ridicarea calit ăŃii activit ăŃii de conducere la toate nivelele.

Perfec Ńionarea acestor activit ăŃi are ca premiz ă informaŃia . În sens primar, termenul de informa Ńie
înseamn ă o în știin Ńare, în general „un mesaj despre anumite lucruri sa u evenimente care au avut, au,
sau vor avea loc".

Prin informa Ńie se în Ńelege orice mesaj care m ăre ște gradul de cunoa ștere al unei fiin Ńe umane în
raport cu mediul înconjur ător (altfel spus, informa Ńia reprezint ă cantitatea de noutate adus ă de un
mesaj din lumea real ă înconjur ătoare), fiind elementul cel mai dinamic al sistemel or informa Ționale,
respectiv informatice, fiind elementul care d ă via Ńă acestor sisteme. În activitatea de conducere
informa Ńia este „materia prim ă" cu care se lucreaz ă în vederea lu ării deciziilor. Informa Ńia reprezint ă
obiectul prelucr ării și totodat ă, principala categorie de resurse utilizate în sist emele informa Ńionale,
respectiv informatice, al ături de celelalte categorii de resurse: personalul de specialitate, echipamentele
de prelucrare și instrumentele de utilizare a acestor echipamente (metode și tehnici de analiz ă și
proiectare, limbaje de programare, pachete standard de programe de aplica Ńii, sisteme de operare,
metode și tehnici de organizare și prelucrare a informa Ńiei etc.).

Cu cât informa Ńia este mai clar ă, mai concisă cu atât deciziile luate sunt mai corecte. Ea este cea care
st ă la baza formul ării deciziilor, a ac Ńiunilor și a îndeplinirii obliga Ńiilor. La baza informa Ńiei st ă
no Ńiunea de dată . Prin dat ă se în Ńelege orice mesaj primit de un receptor, sub o anumit ă form ă. Nu
orice dat ă poate fi o informa Ńie. Rela Ńia dintre date și informa Ńii este ilustrat ă în figura 1.1.

Fig.1.1. – Rela Ńia dintre informa Ńii și date
O defini Ńie foarte concret ă asupra diferen Ńei dintre informa Ńie și dat ă a fost dat ă de Peter Ferdinand
Drucker (1909-): „ Informa Ńia este o dat ă plin ă de scop și de în Ńeles ”.

Proiectarea sistemelor informatice de gestiune
Noșiuni fundamentale E 5 Toate datele care intr ă în sistem sunt analizate, triate și numai o parte dintre ele vor alc ătui informa Ńiile
necesare lu ării unei decizii.
1.2. NoŃiunea de sistem
Conceptul de sistem apare în forma embrionar ă înc ă din filozofia antic ă greac ă. Afirmând c ă întregul
este mai mult decât suma p ărŃilor, Aristotel d ă o prim ă defini Ńie no Ńiunii de sistem, care se va dezvolta
și va evolua pentru a ajunge la forma actual ă de abia la începutul secolului XX.

Cel care pune bazele unei teorii închegate privind teoria sistemele (este considerat fondatorul teorie i
generale a sistemelor) este biologul german Ludwig von Bertalanffy (1901-1972) care între anii 1928
și 1950 public ă o serie de lucr ări reprezentând începuturile teoriei generale a sis temelor și a sistemelor
deschise. Astfel, el a dedus principiile universale care sunt valide pentru sisteme în general. În ace st
sens L. von Bertalanffy a reformulat mai întâi conc eptul clasic al sistemului și l-a determinat drept o
categorie prin care se cunosc rela Ńiile dintre obiecte și fenomene [Bertalanffy]. Conceptul nou dat
sistemului reprezint ă un set de componente interdependente, o entitate c omplex ă în care spa Ńiul-timp
arat ă asem ănările structurale.

În general prin sistem se în Ńelege orice sec Ńiune a realit ăŃii în care se poate identifica un ansamblu de
elemente materiale sau nemateriale (echipamente, me tode, tehnici, fenomene, obiecte, procese,
concepte, personal etc) interconectate printr-o mul Ńime de rela Ńii reciproce, precum și cu mediul
înconjur ător și care ac Ńioneaz ă în comun în vederea realiz ării unor obiective bine definite.

În conformitate cu Open University (1980), un siste m este un ansamblu cu un scop (obiectiv), care are
componente (p ărŃi) ce coexist ă în vederea deservirii unui interes uman particular , dar care se schimb ă
la p ărăsirea sistemului.

Pe baza celor spuse mai înainte se poate spune ca p rin sistem se în Ńelege un ansamblu de elemente,
structurat cu ajutorul rela Ńiilor, ale c ărei p ărŃi se afl ă într-o puternic ă interdependen Ńă și independen Ńă
fa Ńă de mediul înconjur ător, atât elemente, cât și rela Ńiile endogene (rela Ńiile dintre elementele
sistemului) sau exogene (rela Ńiile dintre elementele sistemului și mediul înconjur ător) având un
caracter dinamic, iar existen Ńa și func Ńionarea s ă fiind subordonat ă unui scop.

Pentru realizarea func Ńiilor unui sistem sunt necesare informa Ńii. Fiecare sistem are ata șat un anumit
num ăr de informa Ńii, care poart ă amprenta sistemului respectiv. Figura urm ătoare ilustreaz ă corela Ńiile
dintre un sistem, diferite subsisteme, precum și func Ńiile acestuia.

Fig. 1.2. – Rela Ńiile dintre sistem și mediul înconjur ător
Pentru a caracteriza no Ńiunea de sistem este necesar s ă se pun ă în eviden Ńă următoarele cinci
caracteristici (care reies din defini Ńia sistemului):
1. mul Ńimea de elemente;

Proiectarea sistemelor informatice de gestiune
Noșiuni fundamentale E 6 2. rela Ńiile (endogene) între elemente sistemului;
3. rela Ńiile cu mediul înconjur ător (exogene), intr ările și ie șirile în/ și din sistem;
4. caracterul variabil în timp al elementelor și rela Ńiilor;
5. scopul, finalitatea sistemului.
Societatea comercial ă (firma) ca exemplu de sistem satisface în totalita te cele cinci laturi ale defini Ńiei
unui sistem:
1. mul Ńimea de elemente este alc ătuit ă din: salaria Ńii, elementele materiale, cl ădiri, materii prime,
produse, mijloace financiare, informa Ńionale etc.;
2. , 3. și 4. Rela Ńiile între aceste elemente, cât și cu mediul înconjur ător, au un caracter dinamic,
complex;
5. scopul este de a fabrica produse și a presta servicii, ob Ńinând beneficii.
Se poate rezuma c ă un sistem este un ansamblu de elemente; fiecare el ement al sistemului poate fi un
subsistem, care la rândul lui poate fi considerat s istem format din elemente. Mul Ńimea rela Ńiilor între
componentele unui sistem, precum și a rela Ńiilor între componente și ansamblu formeaz ă structura
sistemului . Modul în care elementele unui sistem sunt dispuse între ele reprezint ă structura static ă a
sistemului. Dac ă leg ătura dintre aceste elemente este de compozi Ńie, de apartenen Ńă , de utilizare, de
vizibilitate a unui element asupra altuia, se spune c ă exist ă o rela Ńie static ă între elemente; de
asemenea exist ă și o interfa Ńă , care reprezint ă schimbul dinamic între dou ă elemente (un flux de
informa Ńii). Mul Ńimea caracteristicilor unui sistem, la un moment da t, determin ă starea sistemului . Un
sistem î și adapteaz ă comportamentul la cerin Ńele mediului s ău. De capacitatea de adaptare a sistemului
și de viteza de reac Ńie va depinde durata s ă de supravie Ńuire. Reac Ńia sistemului la un stimul trebuie s ă
fie cât mai rapid ă și cât mai adecvat ă cu putin Ńă . [V ătui, 2000].

Sistemele sunt de mai multe tipuri, iar în func Ție de criteriul de clasificare utilizat acestea sun t:
/lozenge6 dup ă natura lor:
• sisteme naturale (organismele vii);
• sisteme elaborate (tehnice, economice, conceptuale – aici se reg ăsesc sistemele
informa Ńionale);
/lozenge6 dup ă modul de func Ńionare:
• deschise (ie șirile nu influen Ńeaz ă intr ările);
• închise (intr ările sunt influen Ńate de c ătre ie șiri);
/lozenge6 dup ă comportament:
• deterministe (se cunosc intr ările, ie șirile, și regulile care leag ă intr ările de ie șiri);
• probabilistice (nondeterministe, incerte).
1.3. NoŃiunea de sistem cibernetic
Pentru analiza comportamentului sistemelor, în ansa mblul lor, s-a propus conceptul de „cutie neagr ă”
care reprezint ă sistemul privit ca un tot, f ăcând abstrac Ńie de procesele sale interne. Cutia neagr ă
prime ște impulsuri din partea mediului înconjur ător ( intr ările în sistem) și dup ă ce preia aceste
impulsuri, le transform ă în ac Ńiuni asupra mediului ( ie șirile din sistem).

Acest sistem devine sistem cibernetic , atunci când apare fenomenul de reglare (numit ă conexiune
invers ă sau feed-back ), și care poate fi caracterizat ca în figura 1.3.

Sintetizând, se poate spune c ă no Ńiunea de sistem cibernetic a ap ărut ca o necesitate de a privi un
anumit sistem izolat din punct de vedere informa Ńional. Aceasta presupune c ă în acest sistem cantitatea
de informa Ńie este finit ă, c ă orice intrare de informa Ńie din mediu în sistem (intrare informa Ńional ă) și
orice ie șire de informa Ńie din sistem în mediu (ie șire informa Ńional ă) sunt controlabile sau observabile.
Prin sistem cibernetic se în Ńelege deci un sistem având cel pu Ńin o bucl ă de reglaj (feed-back) prin
care se aplic ă de la ie șirea sistemului un semnal la intrarea acestuia, und e un mecanism de compara Ńie

Proiectarea sistemelor informatice de gestiune
Noșiuni fundamentale E 7 permite ca rezultatul compunerii semnalului de ie șire cu cel de intrare s ă fie transmis blocului de
decizie.

Fig. 1.3. – Leg ătura feed-back într-un sistem cibernetic
Sistemele cibernetice constituie o clas ă important ă de sisteme, iar – dup ă cum se va vedea – sistemele
informa Ńionale și informatice sunt sisteme cibernetice. Schema clas ic ă a unui sistem cibernetic cu o
bucl ă de reglaj este ar ătat ă în figura urm ătoare.

Fig. 1.4. – Leg ătura feed-back într-un sistem cibernetic
Un exemplu simplu ne poate ar ăta diferen Ńa între un sistem și un sistem cibernetic: de pild ă, un
autoturism este un sistem mecano-electric, dar nu e ste un sistem cibernetic, un autoturism împreun ă cu
conduc ătorul auto constituie un sistem cibernetic.
1.4. NoŃiunea de sistem informaŃional
Un sistem poate fi controlat printr-un alt sistem, denumit sistem de conducere / comand ă sau de
pilotaj . Acest sistem de conducere intr ă în leg ătur ă cu un sistem operant ce asigur ă, la rândul s ău,
transformarea unor fluxuri de intrare în fluxuri de ie șire.

Sistemul de conducere are la baz ă anumite obiective determinate de specificul domeni ului analizat,
cadrul legislativ în materie și cerin Ńele strategice ale domeniului. Rezult ă c ă sunt fixate obiective clare
și directe pentru procesul de management, ce trebuie îndeplinite prin interac Ńiunea dintre sistemul de
conducere și cel operant.

Între sistemul de conducere și cel operant intervine un sistem informa Ńional (un sistem de interfa Ță
între sistemul de conducere Ți cel operant), definit ca un set finit de concepte , metode, tehnici,
procedee, modele, instrumente și procese utilizate pentru prelucrarea informa Ńiilor și a interac Ńiunilor
provenite de la sistemul operant, în vederea transf orm ării lor în date ce pot fi furnizate sistemului de
conducere, în condi Ńii de eficien Ńă economic ă acceptabil ă, într-un context opera Ńional controlabil, în
limitele cadrului legal al domeniului supus analize i, în scopul realiz ării func Ńiilor organismului
respectiv și a atributelor conducerii acestuia.

Potrivit teoriei sistemelor orice organism con Ńine aceste trei subsisteme: de conducere, informa Ńional și
operant. Fiecare dintre aceste subsisteme au un rol bine definit, și anume:
/lozenge6 sistemul operant (condus) este acela pe care se bazeaz ă activitatea organismului analizat, și care
are rolul de a transforma fluxurile primare și / sau informa Ńionale în fluxuri secundare sau de
prelucrare;
/lozenge6 sistemul de conducere (de pilotaj) asigur ă declan șarea activit ăŃii decizionale aplicat ă întregului
organism analizat. Acest subsistem permite monitori zarea, reglarea, coordonarea și controlul
activit ăŃii respectivului organism în mediul s ău specific. El decide asupra organiz ării, evolu Ńiei și

Proiectarea sistemelor informatice de gestiune
Noșiuni fundamentale E 8 interconexiunilor cu subsistemul operant și informa Ńional. În acest context, sistemul de conducere
este implicat fundamental în asigurarea eficien Ńei activit ăŃii organismului;
/lozenge6 subsistemul informa Ńional îndepline ște rolul de prelucrare manual ă / automat ă a informa Ńiilor
transmise de c ătre sistemul operant, în raport cu cerin Ńele cadrului legislativ și cu particularit ăŃile
organiz ării și func Ńion ării domeniului analizat, în scopul furniz ării datelor necesare controlului
activit ăŃii globale asigurate de c ătre sistemul de conducere. Practic, subsistemul inf orma Ńional
asigur ă, în general, stocarea, prelucrarea și difuzarea datelor necesare subsistemelor de inter fa Ńă :
de conducere și operant. Putem spune c ă subsistemul informa Ńional are urm ătoarele func Ńii:
• cunoa șterea și specificul prelucr ărilor realizate la nivelul subsistemului operant;
• furnizarea de date pertinente, exacte și operative subsistemului de conducere;
• implementarea func Ńiilor esen Ńiale relative la informa Ńiile cu specific caracteristic domeniului
analizat:
/rhombus4 generarea de informa Ńii;
/rhombus4 memorarea acestor informa Ńii;
/rhombus4 prelucrarea acestor informa Ńii;
/rhombus4 comunicarea acestor informa Ńii.
Se observ ă c ă sistemul informa Ńional se afl ă în rela Ńie de subordonare fa Ńă de sistemul de conducere al
sistemului. Rela Ńia de subordonare este dat ă de faptul c ă sistemul informa Ńional trebuie s ă produc ă
acele informa Ńii care sunt utile procesului de conducere al siste mului. Aceasta se concretizeaz ă prin
cerin Ńele și deciziile emise de acesta fa Ńă de sistemul informa Ńional.

Tot prin sistem informa Ńional mai în Ńelegem și partea dintr-un sistem care r ăspunde sensului restrâns al
analizei, adic ă sistemul privit exclusiv din punct de vedere al cu legerii, transmiterii, prelucr ării și
stoc ării informa Ńiilor. O defini Ńie complet ă a no Ńiunii de sistem informa Ńional a fost dat ă de
Buckingham (1987): “ Sistem informa Ńional este un sistem care asambleaz ă, memoreaz ă, prelucreaz ă
și ob Ńine informa Ńii relevante pentru o organiza Ńie (sau pentru o societate) astfel încât informa Ńiile s ă
fie accesibile și utile celor care doresc s ă le utilizeze și anume: manageri, staf, clien Ńi și cet ăŃeni.
Sistemul informa Ńional este un sistem care presupune activitate uman ă (social ă) care poate implica
sau nu prelucrarea pe calculator ”.

Sistemul informaŃional reprezint ă ansamblul informa Ńiilor, surselor și nivelurilor consumatoare,
canalelor de circula Ńie, procedurilor și mijloacelor de tratare a informa Ńiilor din cadrul sistemului
căruia îi este ata șat. Sistemul informa Ńional se mai poate defini drept ansamblul de resurs e, circuite și
procese informa Ńionale. Orice activitate specific ă, sau organism specific, are un sistem informa Ńional
specific.

În societatea uman ă orice activitate este definit ă de acte normative, care implicit determin ă și
delimiteaz ă și sistemul informa Ńional aferent acestei activit ăŃi.

Orice sistem informa Ńional trebuie s ă asigure organismului c ăruia îi apar Ńine informa Ńii complete, în
cantit ăŃi suficiente, corecte și la nivelul de operativitate cerut de nivelele con sumatoare. Orice firm ă
are propriul s ău sistem informa Ńional, care ajut ă conducerea firmei, prin informa Ńiile care le
furnizeaz ă, s ă ia deciziile optime pentru conducerea acesteia.

Sistemul informa Ńional are un scop propriu și anume acela de a deservi activitatea de conducere cu
informa Ńii de fundamentare a deciziilor și are și metode proprii de realizare a scopului.

În cadrul sistemului informa Ńional economic se disting dou ă subsisteme care se afl ă în rela Ńii de
interdependen Ńă asigurând în acela și timp și existen Ńa întregului sistem într-o stare de echilibru (figu ra
1.5.). Cele dou ă subsisteme sunt:
• sistemul conduc ător al procesului informa Ńional;
• procesul informa Ńional al sistemului economic.

Proiectarea sistemelor informatice de gestiune
Noșiuni fundamentale E 9

Fig. 1.5. – Rela Ńiile dintre cele dou ă subsisteme
ale sistemului informa Ńional
În cadrul procesului informaŃional au loc o serie de transform ări prin intermediul c ărora datele despre
sistemul condus (real) și informa Ńiile primite din afar ă sunt transformate în informa Ńii utile procesului
de conducere a sistemului economic. Procesul inform a Ńional poate fi separat pe mai multe etape și
anume:
1. etapa de culegere a informa Ńiilor , care face leg ătura direct ă cu sistemul real din care rezult ă
datele;
2. o etap ă de prelucrare a informa Ńiilor în care datele intr ă în componen Ńa diferitelor modele, sufer ă
o serie de procese de grupare, selectare, astfel în cât se ob Ńin informa Ńii necesare procesului de
conducere.
În interiorul și între aceste etape, informa Ńia circul ă prin a șa numitul proces de transmitere a
informa Ńiei.

Sistemul conducător al procesului informaŃional prime ște de la procesul informa Ńional informa Ńii
referitoare la comportamentul acestuia; de asemenea mai prime ște de la sistemul conduc ător al
organismului economic, cerin Ńe și decizii privitoare la nevoile de informare ale ac estuia. Pe baza
acestor cerin Ńe sistemul conduc ător al procesului informa Ńional întocme ște programe prin intermediul
cărora procesul informa Ńional s ă poat ă furniza sistemului conduc ător al organismului economic
informa Ńiile cerute. De asemenea, se pot întocmi programe privitoare la înl ăturarea unor informa Ńii
considerate inutile, îmbun ătăŃirea calit ăŃii informa Ńiei conform constat ărilor în procesul utiliz ării lor,
modificarea termenelor de livrare etc.

Sistemul informa Ńional se afl ă în rela Ńie de subordonare fa Ńă de sistemul de conducere al sistemului
economic. Rela Ńia de subordonare este dat ă de faptul c ă sistemul informa Ńional trebuie s ă produc ă
acele informa Ńii care sunt utile (cerute) procesului de conducere al sistemului economic. Aceasta se
concretizeaz ă prin cerin Ńele și deciziilor emise de acesta fa Ńă de sistemul informa Ńional.
1.5. NoŃiunea de sistem informatic
Elementul revolu Ńionar al muta Ńiilor care au determinat saltul calitativ al sistem elor informa Ńionale este
axat pe dezvoltarea și perfec Ńionarea mijloacelor tehnice și a procedurilor de prelucrare a informa Ńiilor
în scopul automatiz ării prelucr ării datelor. Automatizarea prelucr ării datelor cu ajutorul calculatorului
electronic prezint ă saltul calitativ major de automatizare a unor p ărŃi ale sistemului informa Ńional.

Apari Ńia calculatoarelor electronice și constituirea informaticii ca știin Ńă , reprezint ă al treilea moment
important în istoria informa Ńional ă a omenirii, dup ă limbaj și tipar. Calculatorul electronic a produs o
revolu Ńie în societatea uman ă în ansamblul ei, cu implica Ńii deosebite în sfera informa Ńional ă (prin
modificarea activit ăŃii intelectuale a omului), cu preponderen Ńă în activitatea de conducere
(management).

Proiectarea sistemelor informatice de gestiune
Noșiuni fundamentale E 10 Dezvoltarea echipamentelor de calcul și îndeosebi a calculatoarelor a contribuit la perfe c Ńionarea
modelelor economice, ceea ce a f ăcut posibil ă apari Ńia sistemelor informatice și de conducere. Astfel,
informatica se integreaz ă organic în activitatea economic ă și social ă, iar domeniile de utilizare a
acestora se diversific ă în ritm rapid, prin includerea unor noi activit ăŃi umane.

łinând cont de cele spuse mai înainte se poate afirm a c ă partea automatizat ă cu ajutorul calculatorului,
din cadrul sistemului informa Ńional al unui sistem se nume ște sistem informatic (prima dat ă aceste
sisteme erau cunoscute sub denumirea de sisteme de prelucrare automat ă a datelor , SPAD ).

O defini Ńie prim ă defini Ție a unui sistem informatic “prin sistem informatic se în Ńelege ansamblul de
componente hardware/software, proceduri și oameni reunite și organizate pentru a prelucra date, în
vederea îndeplinirii anumitor sarcini și realiz ării unor performan Ńe m ăsurabile prin criterii stabilite”.

O defini Ție complet ă: sistemul informatic este format dintr-un set finit de metode, tehnici, procedee,
modele, strategii, instrumente, sisteme de tehnic ă de calcul, sisteme de comunica Ńie de date, personal
specializat în informatic ă, sisteme organizatorice, restric Ńii și facilit ăŃi legislative în materie, utilizate
pentru generarea, transmiterea, prelucrarea algorit mic ă, difuzarea și interpretarea rezultatelor în
vederea îndeplinirii func Ńiilor organismului și a atributelor sistemului de gestiune (monitorizar ea,
reglarea, coordonarea, controlul). Toate aceste ele mente au rolul de a asigura o func Ńionare optim ă și o
reglare de tip conexiune invers ă (feed-back) a întregului sistem aferent unui organ ism , în condi Ńii de
eficien Ńă economic ă și rentabilitate financiar ă acceptabile.

Sistemul informatic poate avea caracter informa Ńional-decizional sau numai strict informa Ńional, dup ă
cum este sau nu orientat spre rezolvarea, al ături de problemele pur informa Ńionale, și a celor
decizionale.

Din defini Ńia sistemului informatic rezult ă c ă între acesta și sistemul informa Ńional, c ăruia îi este
subordonat, exist ă anumite raporturi, care în principal se refer ă la:
1. existen Ńa unui raport de compozi Ńie, sau apartenen Ńă prin care sistemul informatic este o parte a
sistemului informa Ńional;
2. orice sistem informatic exist ă numai în cadrul unui sistem informa Ńional care-l cuprinde și-l
subordoneaz ă func Ńional, utilizându-l ca infrastructura s ă tehnic ă;
3. sistemul informatic poart ă amprenta organismului pe care îl reprezint ă.

Fig.1.6. – Sructura unui sistem informatic
Sistemul informatic se poate prezenta sub forma une i „ cutii negre ”, caracterizat ă de intr ări, ie șiri,
reguli, proceduri, mijloace și metode.

Sistemul informatic prime ște datele de la sistemul operant și, prin intermediul unei baze de proceduri
asociate, asigur ă prelucrarea multipl ă a acestora, în conformitate cu un sistem procedura l bazat pe
algoritmi de prelucrare și de calcul, în vederea ob Ńinerii unor date de ie șire sub form ă de rapoarte,
indicatori sintetici, grafice, alte ie șiri sub form ă mixt ă și / sau ie șiri c ătre alte sisteme informatice.

Proiectarea sistemelor informatice de gestiune
Noșiuni fundamentale E 11 În mod practic, sistemul informatic folose ște colec Ńii de date organizate sub form ă de:
/lozenge6 baze de date gestionate prin sisteme de gestiune a bazelor de date (SGBD);
/lozenge6 baze de tabele gestionate prin sisteme de tip LOTUS sau derivate din acestea (EXCEL,
QUATTRO).
Intrările sunt asigurate prin opera Ńiunile externe generate de activitatea desf ăș urat ă la nivelul
sistemului (subsistemului) operant, opera Ńii ce genereaz ă un flux de date care vor determina opera Ńii de
actualizare asupra bazelor de date. Deci, intrarea unui sistem informatic este informa Ția care se
înregistreaz ă, sub forma datelor de intrare, în sistemul informa tic respectiv, cu scopul de a fi
prelucrat ă. Intr ările unui sistem informatic reprezint ă totalitatea datelor introduse în sistem cu scopul
de a fi prelucrate, în conformitate cu regulile fun c Ționale Ți / sau organizatorice specifice sistemului
economic care-l utilizeaz ă Ți cu legisla Ția în vigoare.

Intr ările unui sistem informatic pot fi ob Ținute prin:
• Introducerea datelor din documente (tastatur ă, scanare).
• Transfer electronic de date (re Țea local ă, re Țea de arie întins ă).
Prelucrările unui sistem informatic reprezint ă totalitatea opera Țiilor efectuate asupra datelor
înregistrate în și respectiv pentru ob Ținerea informa Țiilor necesare func Țion ării unui sistem
economic.

Ieșirile unui sistem informatic reprezint ă totalitatea rezultatelor prelucr ărilor efectuate asupra
datelor înregistrate în și respectiv, prin interpretarea c ărora se pot ob Ține informa Țiile care
fundamenteaz ă deciziile manageriale pe toate nivelele organizato rice ale sistemului economic care îl
utilizeaz ă. Ele reprezint ă:
• Datele de pe documentele întocmite de sistem.
• Datele exportate c ătre alte sisteme informatice.
Reiese faptul c ă ie șirile sunt ob Ńinute ca urmare a prelucr ării datelor de intrare, fiind concretizate în
urm ătoarele tipuri de rapoarte:
/lozenge6 rapoarte – liste – situa Ńii : con Ńin indicatori sintetici și / sau analitici sub form ă tabelar ă, ob Ńinu Ńi
prin diferite procese de prelucrare aplicate asupra colec Ńiilor de date, fiind necesare lu ări de
decizii cu caracter tactic, strategic și operativ;
/lozenge6 indicatori sintetici : con Ńin elemente sintetice / analitice cu un grad maxim de prelucrare și
reprezentative, afi șabile pe ecran, și sunt folosite pentru informarea și luarea operativ ă a
deciziilor de c ătre manageri sau personalul de specialitate;
/lozenge6 grafice : arat ă tendin Ńa unor fenomene sau procese pe o perioad ă de timp sau ponderea unor
elemente într-un asemenea fenomen;
/lozenge6 mixte : se prezint ă sun forma unor documente elaborate pentru factorii de decizie și con Ńin text
explicativ, repoarte, indicatori sintetici și grafice, inclusiv combina Ńii ale acestor tipuri de ie șiri;
/lozenge6 ie șiri c ătre alte sisteme informatice : sunt utilizate pentru transmiterea on-line de dat e între
diverse organisme, fiind necesare inform ării reciproce sau raport ării cu privire la fenomene și
procesele actuale, trecute și / sau viitoare .
Principalele obiective ale unui sistem informatic sunt:
1. cunoa șterea st ării sistemului;
2. cuantificarea rezultatelor sistemului;
3. cre șterea operativit ăŃii în activitatea managerial ă a sistemului;
4. utilizarea eficient ă a resurselor sistemului.
Fiecare organism (societate, întreprindere, firm ă) are de îndeplinit mai multe atribu Ńii pentru a-și
atinge scopul pentru care a fost creat (pentru care , de fapt, func Ńioneaz ă). Pentru ca un sistem
informatic s ă fie integrat unui organism el trebuie s ă fie ata șat în mod intim tuturor func Ńiunilor

Proiectarea sistemelor informatice de gestiune
Noșiuni fundamentale E 12 automatizabile din cadrul acestuia. Deci fiec ărei func Ńiuni a organismului, îi va corespunde un
subsistem informatic, care toate împreun ă vor alc ătui sistemul informatic al acestuia.
Înc ă de la începutul utiliz ării tehnicii de calcul în prelucrarea datelor la ni velul unei organiza Ńii s-a
impus necesitatea ca sistemul informatic s ă fie împ ărŃit în mai multe subsisteme. Partea sistemului
informatic asociat ă unei func Ńiuni se nume ște subsistem și este caracterizat ă de un ansamblu de
opera Ńiuni similare care realizeaz ă obiectivele sistemului pentru partea automatizat ă din func Ńiunea
respectiv ă.

Împ ărȚirea pe subsisteme a fost determinat ă de o serie de factori precum:
1. tipul de produc Ńie și ramura din care face parte întreprinderea;
2. gradul de complexitate al sistemului informatic;
3. experien Ńa și num ărul membrilor echipei de proiectare;
4. condi Ńiile existente în întreprindere și caracteristicile sistemului informa Ńional existent;
5. gradul de utilizare al echipamentelor;
6. situa Ńia codific ării și calitatea documenta Ńiei;
7. gradul de preg ătire al documenta Ńiei de proiectare și tehnologice etc.
Astfel s-au constituit „subsisteme” pe:
1. func Ńiunile întreprinderii (produc Ńie, comercial, financiar-contabil, personal etc.);
2. pe grupuri de activit ăŃi de conducere (planificare și urm ărire, gestiunea stocurilor, programarea,
lansarea și urm ărirea fabrica Ńiei, gestiunea livr ărilor etc.);
3. subsistemul care con Ńine modelele pentru preg ătirea deciziilor;
4. subsistemul care asigur ă gestiunea bazei de date etc.
Modul de constituire al subsistemelor a fost în gen eral influen Ńat de gîndirea „realiz ării de aplica Ńii”,
care a premers gîndirii sistemice; care consider ă c ă împ ărŃirea pe subsisteme trebuie subordonat ă în
principal necesit ăŃilor implement ării sistemului informatic, sau mai corect al diferi telor p ărŃi ale
sistemului informatic și, deasemenea, trebuie avut în vedere în mod consec vent caracterul cibernetic al
oric ărui subsistem al sistemului informatic (structurat ca sistem cibernetic).

Deoarece în cadrul oric ărui ansamblu de opera Ńiuni se pot regrupa subansambluri de opera Ńiuni de
acela și tip, tot a șa în cadrul unui subsistem se pot decupa subsisteme , denumite și aplica Ńii, tratate pe
calculator ca lucr ări independente. Aplica Ńia, sau subsistemul, st ă în raport cu subsistemul cum st ă
partea fa Ńă de întreg.

Cele mai importante subsisteme, din cadrul unui sis tem al firmei, sunt:
1. subsistemul de resurse umane;
2. subsistemul de produc Ńie;
3. subsistemul financiar –contabil;
4. subsistemul de marketing.
În cazul societ ăŃilor industriale sistemul informatic se structureaz ă de obicei în urm ătoarele
subsisteme:
• planificarea tehnico-economic ă;
• preg ătirea fabrica Ńiei;
• programarea, lansarea și urm ărirea produc Ńiei;
• marketing;
• personal-salarizare;
• financiar – contabil.

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 13 Capitolul 2
Sisteme informatice
Pornind de la defini Ția sistemului informatic, sistemul informatic este format dintr-un set finit de
metode, tehnici, procedee, modele, strategii, instr umente, sisteme de tehnic ă de calcul , sisteme de
comunica Ńie de date , personal specializat în informatic ă, sisteme organizatorice , restric Ńii și facilit ăŃi
legislative în materie, utilizate pentru generarea, transmiterea, prelucrarea algoritmic ă, difuzarea și
interpretarea rezultatelor în vederea îndeplinirii func Ńiilor organismului și a atributelor sistemului de
gestiune (monitorizarea, reglarea, coordonarea, con trolul), se poate defini arhitectura unui sistem
informatic, care este alc ătuit din urm ătoarele componente:
/lozenge6 sistemul de tehnic ă de calcul este acel sistem care permite realizarea anumitor activi tăŃi, având
la baz ă prelucrarea informa Ńiei, alc ătuit din dou ă subsisteme principale: hardware și software ,
este deci alc ătuit din calculatoarele, împreun ă cu produsele software utilizate, care sunt puse la
dispozi Ția utilizatorilor sistemului informatic;
/lozenge6 sistemul de comunica Ție de date este reprezentat de ansamblul de mijloace tehnice
interdependente care asigur ă transferul informa țiilor între dou ă sisteme de calcul oarecare,
aflate la o anumit ă distan ță unul fa ță de altul . Un sistem de comunica Ție leag ă între ele dou ă
sau mai multe calculatoare cu scopul de a asigura t ransferul de date între ele, prin intermediul
unei re Țele de calculatoare. În func Ție de tipul re Țelei de calculatoare (re Țea local ă,
metropolitan ă, de arie întins ă etc.) aceste sisteme de comunica Ție sunt mai mult sau mai pu Țin
complexe. Datorit ă faptului c ă în ultimii ani Internet-ul a început s ă fie utilizat ca suport pentru
afacerile firmelor dezvoltarea acestor sisteme de c omunica Ție cap ătă o amploare din ce în ce mai
mare.
/lozenge6 personalul specializat în informatic ă Ți utilizatorii, sau sistemul de resurse umane , este format
din mul țimea de persoane cu preg ătire diferite care interac ționeaz ă cu sistemul informatic în
vederea îndeplinirii func țiilor acestuia . În func Ție de sarcinile Ți / sau funcȚiile pe care le
ocup ă fiecare persoan ă în raport cu sistemul informatic de dezvoltat, sau utilizat, raport care este
stabilit în func Ție de nivelul de preg ătire a fiec ărei persoane în parte, aceasta va face parte dintr-
o anumit ă categorie de personal: personal de specialitate Ți personalul de exploatare.
/lozenge6 sistemul organizatoric reprezint ă totalitatea metodelor ți tehnicilor organizatorice utilizate în
vederea atingerii func ției sistemului informatic .
Sistemele informatice depind în mod esen Ńial de resursele software care ajut ă utilizatorii s ă lucreze cu
echipamentul hardware și s ă acceseze re Ńelele de calculatoare. Astfel software-ul asigur ă introducerea,
prelucrare, ie șirea, datelor precum și controlul sistemelor informatice.
2.1. Categorii de produse software
Software-ul se clasific ă în dou ă mari categorii de programe:
A. Software-ul de aplica ii este reprezentat de programele care ac Ńioneaz ă direct asupra unui
domeniu de utilizare particular pentru a asigura pr ocesarea informa Ńiilor necesare utilizatorilor
finali. Acest tip de programe se reg ăse Țte într-o multitudine de variante, versiuni, platfo rme de
lucru, produc ători și pre Ń. Software-ul de aplica Ńii are o zon ă determinat ă de utilizare (de
exemplu, domeniul economic) iar în cadrul ei, zona poate fi și mai specific ă (de exemplu, calcul
tabelar). În prezent se remarc ă folosirea cu prec ădere de pachete integrate ( suite ) pentru
activit ăŃile de birou care au un rol important în cre șterea produc Ńivit ăŃii. Acestea cuprind:
procesor de texte, calcul tabelar, baze de date, pr ograme de prezentare și de lucru pe Internet.
Cele mai importante aplica Ńii de acest tip sunt: MS Office, Corel Word Perfect Office, Lotus
Smart Suite și Sun Star Office.

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 14 O clasificare a acestora pentru domeniul economic p oate fi:
1. Programe de procesare de text.
2. Programe de calcul tabelar.
3. Programe de management al bazelor de date.
4. Programe de prezent ări și grafic ă.
5. Programe de lucru în Internet și po ștă electronic.
Avantajele acestor grupuri de aplica Ńii sunt:
/rhombus4/rhombus4 /rhombus4/rhombus4 determin ă cre șterea productivit ăŃii, faciliteaz ă comunica Ńia în interiorul organiza Ńiei, permit
lucrul în re Ńea și integreaz ă aplica Ńiile Internet;
/rhombus4/rhombus4 /rhombus4/rhombus4 includ toate tipurile de programe necesare activit ăŃii de birou;
/rhombus4/rhombus4 /rhombus4/rhombus4 costul achizi Ńiei unui pachet integrat este mai mic decât al apli ca Ńiilor cump ărate individual;
/rhombus4/rhombus4 /rhombus4/rhombus4 toate aplica Ńiile din pachet arat ă aproape identic ceea ce le face mai u șor de înv ăŃat și de
lucrat;
/rhombus4/rhombus4 /rhombus4/rhombus4 au facilit ăŃi importante de transfer al informa Ńiilor dintr-o aplica Ńie în alta.
Dezavantaje:
/rhombus4 multe din facilit ăŃile oferite de aceste programe nu sunt folosite de utilizatori;
/rhombus4 au nevoie de resurse mari pentru a func Ńiona corespunz ător (spa Ńiu pe disc, memorie);
/rhombus4 pot afecta viteza de lucru și puterea sistemului.
Tot în aceast ă categorie produc ătorii de software au dezvoltat o categorie de pache te integrate de
nivel mediu care au preluat o serie din caracterist icile celor de mai sus. Acestea combin ă func Ńiile
mai multor tipuri de programe în unul singur. Cele mai cunoscute sunt: MS Works, Lotus Works,
Claris Works. Ca avantaje ar putea fi resursele mod este pe care le utilizeaz ă și costul sub 100 US
$, iar dezavantajul este c ă nu au performan Ńele programelor individuale.
B. Software-ul de sistem sunt programele care gestioneaz ă și manipuleaz ă resursele și activit ăŃile
unui computer fiind o interfa Ńă între computer și software-ul de aplica Ńii. În aceast ă categorie se
includ urm ătoarele programe:
1. Sisteme de operare – asigur ă interfa Ța dintre calculator Ți sofyware-ul de aplica Ții.
Exemple: MS DOS,Windows, Linux, Mac OS, OS2 etc.
Sistemul de operare este un program principal, perm anent stocat în memorie, lansat în
execu Ńie la pornirea calculatorului care îndepline ște func Ńii de coordonare și control asupra
resurselor fizice ale calculatorului și care intermediaz ă dialogul om-calculator. Deci, el asigur ă
și alte facilit ăŃi ca vizualizarea de fi șiere, ștergere, copieri de fi șiere. Mai are rolul de a
înmagazina și reg ăsi datele pe disc, organizeaz ă intr ările de date de la tastatur ă, trimite datele
către imprimant ă și verific ă dac ă tip ărirea decurge normal, controleaz ă monitorul. Exist ă
diverse sisteme de operare, diferite între ele în f unc Ńie de arhitectura calculatorului, codurile
ma șin ă, instruc Ńiuni etc.
Scopul unui sistem de operare este de a face comenz ile ma șinii „transparente” utilizatorului.
Acela și sistem de operare poate fi implementat pe o varie tate larg ă de ma șini, cu viteze și
capacit ăŃi diferite. Cele mai multe softuri sunt f ăcute ca lucrul cu ele s ă fie intermediat de
sistemul de operare. Datorit ă faptului c ă sistemul de operare este acela și, programele pot rula
pe diverse tipuri de computer f ără sau cu mici modific ări. Acest element de portabilitate a
ajutat ca softul s ă se diversifice.
2. Programe de re Ńea – care asigur ă comunica Ńia dintre calculatoare. De exemplu: Windows NT,
2000 sau Novell.
3. Programe utilitare – ce efectueaz ă diverse activit ăŃi precum: diagnoza utiliz ării sistemului și
resurselor, protec Ńia antivirus, arhivarea documentelor, optimizarea s istemului etc.
2.1.1. Procesoarele de text
A da o defini Ńie exact ă unui procesor de texte este o activitate hazardat ă, sortit ă e șecului, datorit ă
complexit ăŃii și diferen Ńelor specifice între atât de diversele pachete numi te procesoare de texte . Cert
este c ă un procesor de texte este un pachet de programe ce lucreaz ă asupra unui text în vederea

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 15 imprim ării acestuia, chiar dac ă textul va fi transmis prin fax sau po ștă electronic ă, va fi stocat în fi șiere
text, ce vor reprezenta surse ale unui program sau documenta Ńii on-line etc.
Evoluând de la minieditoare de texte, cu performan Ńe sc ăzute, ca Edit pentru sistemul de operare MS-
DOS, Write pentru sistemul de operare Windows și ajungând pân ă la procesoare profesionale ca Word
for Windows , AmiPro , JustWrite , procesoarele de texte realizeaz ă acum toate opera Ńiile necesare
pentru editare, machetare, formatare, vizualizare, tip ărire, verificare și multe alte opera Ńii ce dau unui
text un aspect foarte pl ăcut și atractiv. R ăspândirea interfe Ńelor grafice, de tipul WYSIWYG ( What
You See Is What You Get – ceea ce vezi (pe ecran ) este ceea ce vei avea (la imprimant ă)), au dus la
apropierea din ce în ce mai mare a tipografului, te hnoredactorului, secretarei și nu în ultimul rând, al
oric ărui om ce vrea s ă scrie un text, de calculator prin procesorul de te xte și îndep ărtarea s ă de ma șina
de scris clasic ă.

Integrarea aplica Ńiilor . Procesoarele de texte nu lucreaz ă în general singure, ci coopereaz ă cu alte
aplica Ńii ce realizeaz ă opera Ńii complexe. Orice program care se respect ă știe s ă se descurce cu câteva
formate grafice, spreadsheet-uri, cu formatele celo r mai populare baze de date și mai ales cu diverse
formate de text. Pe lâng ă procesorul de texte se g ăsesc de obicei, un editor de ecua Ńii, un editor de
grafic ă, un editor de stil și art ă și multe altele.

Mediul Windows , prin multitasking (reprezint ă o modalitate de lucru oferit ă de un sistem de operare,
prin care un calculator poate executa mai multe tas k-uri în acela și timp; un task este o aplica Ńie sau
program care este executat la un moment dat), ofer ă procesoarelor de texte posibilitatea de a folosi î n
comun alte aplica Ńii ale sistemului. Astfel, exist ă posibilitatea de a ata șa documente mesajelor trimise
prin fax sau po ștă electronic ă. De asemenea se pot crea leg ături dinamice ( DDE – Dynamic Data
Exchange , realizeaz ă un transfer al datelor dintr-o aplica Ńie Windows în alta, sau OLE – Object
Linking and Embedding , permite inserarea unui obiect creat printr-un anu mit program în interiorul
altui obiect creat printr-un program diferit; leg ătura între cele dou ă obiecte fiind gestionat ă de sistemul
de operare) cu datele unei aplica Ńii Windows , astfel încât orice actualizare a datelor original e se
reflect ă în document, dac ă aplica Ńiile sunt deschise simultan (DDE) sau la cerere (OL E).

Se poate sintetiza c ă programele de procesat text permit crearea, modifi carea și tipărirea de documente
aflate în form ă digital ă. Avantaje utiliz ării lor:
/lozenge6 capacitatea de a edita bro șuri, manuale etc.;
/lozenge6 utilizarea și convertirea de documente din/în formatul HTML pen tru Internet;
/lozenge6 corectarea textului, gramaticii și traducere.
Programele DTP (Desk T Publishing ) sunt programe mai specializate în producerea de c ărŃi, manuale,
bro șuri și care ofer ă mai multe facilit ăŃi în acest domeniu (grile, format ări, stiluri).
2.1.2. Programe de calcul tabelar
Sunt programe utilizate pentru analize de business, planificare și modelare. Acestea ofer ă un mod
electronic de înlocuire a tabelelor de hârtie, crei onului și a calculatorului de buzunar. Programele se
prezint ă sub forma unui tabel cu un num ăr foarte mare de rânduri și coloane, permit combinarea
acestora, calcule, grafice, analize etc. Totodat ă permit accesarea și interogarea bazelor de date de pe
Internet pentru al le prelucra.

Trebuie amintit faptul c ă locul unde s-au cerut pentru prima dat ă calculatoare PC foarte puternice a
fost Wall Street . Domeniul economic este, se pare, unul primordial pentru produc Ńia de hardware și
software. Dac ă din punct de vedere al hardware-ului problemele er au în cea mai mare parte rezolvate,
din p ăcate software-ul era mai pu Ńin dezvoltat și devenise apanajul unor speciali ști. Aceasta a
determinat necesitatea unor programe care s ă fie foarte u șor accesibile și „novicilor”, nemaif ăcând
necesar ă intermedierea prin speciali ști (anali ști progrmatori).

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 16 Cum într-o economie de pia Ńă apari Ńia unei nevoi duce la apari Ńia mijlocului prin care este satisf ăcut ă,
pe fondul dezvolt ării hardware-ului, la începutul anilor 1980 au ap ărut primele programe de calcul
tabelar numite și spreadsheets . Programele de calcul tabelar sunt pachete de prog rame (dac ă sun ă prea
preten Ńios ele se numesc mai simplu programe) care permit manipularea datelor aranjate sub form ă de
tabel. Mai simplu spus pentru cei ce au tangen Ńă cu activitatea de birou, ace Țtia trebuie să se
gândeasc ă la un document cumulativ dar foarte foarte mare.

Avantajele utiliz ării acestor programe const ă în faptul c ă odat ă stabilite formulele, rela Ńiile între celule
și introduse datele, imediat rezultatele calculelor vor fi afi șate și mai mult, la modificarea datelor sau o
alt ă introducere ulterioar ă, rezultatele calculelor vor fi ref ăcute imediat sesizându-se modificarea
intervenit ă.

Posibilitatea de a crea modele fiind foarte dezvolt at ă se pot dezvolta modele extrem de complexe, se
pot elabora și diverse analize și calcule financiare (când ne-am referit la faptul c ă spreadsheet-urile
acoper ă domeniul economic vom mai men Ńiona c ă exist ă o multitudine de func Ńii financiare, contabile,
statistice, matematice și chiar inginere ști, care vin s ă u șureze și mai mult lucrul cu aceste programe).
Aceste analize se pot face u șurin Ńă folosind comenzile what-if (ce s-ar întâmpla dac ă …), solve for
(rezolv ă pentru …) sau optimiz ări.
2.1.3. Software pentru baze de date
Fiecare organiza Ńie lucreaz ă cu un num ăr mai mic sau mai mare de documente și date. Unele date se
afl ă în arhive, altele în circula Ńie, unele sunt create în interior, altele în exteri or. Indiferent de forma,
con Ńinutul sau provenien Ńa lor, ele formeaz ă un volum de informa Ńie care este vital pentru buna
administrare și succesul activit ăŃii respectivei organiza Ńii. Toate aceste colec Ńii de date împreun ă cu
aplica Ńiile ce utilizeaz ă datele respective, formeaz ă o baz ă de date, mai exact o baz ă de date și un
sistem de gestiune a bazelor de date (SGBD), care d e fapt reprezint ă software-ul utilizat pentru
dezvoltarea aplica Țiilor cu baze de date.

Deci bazele de date cuprind colec Ńii structurate de date, sistemul de gestiune a aces tora cu interog ări,
machete, rapoarte, aplica Ńii precum și mediile de interfa Ńare și dezvoltare a aplica Ńiilor referitoare la
colec Ńiile de date.

Gestiunea datelor în cadrul unor organiza Ńii mari sau a celor cu un flux rapid de date devine o
problem ă care consum ă timpul, energia și nervii unui num ăr considerabil de func Ńionari. Consum ă
deci resurse, bani. C ăci indiferent dac ă este vorba de facturi sau de datele secrete ale un ui nou produs,
exist ă situa Ńii în care afaceri extraordinare sau simpla imagine public ă depind de eficien Ńa cu care sunt
manipulate aceste date. Calculatoarele încearc ă s ă fac ă ordine în milioanele de date de diverse tipuri ce
tind s ă sufoce organiza Țiile. Dar în spatele lor trebuie mereu s ă se afle cineva care s ă le conduc ă și s ă
în Ńeleag ă tot fluxul acestora. Folosirea sistemelor de gesti une a bazelor de date în mod eficient
înseamn ă economie de timp, de munc ă, de bani și nu în ultimul rând confer ă competitivitate și stil.
Tr ăsături standard
În orice sistem de gestiune a bazelor de date primu l lucru care trebuie f ăcut este stabilirea structurii
(organiz ării) datelor. Structura rela Ńional ă a reu șit s ă se impun ă în domeniul SGBD-urilor, astfel încât
marea majoritate a acestora sunt rela Ńionale, de aceea se vor trata numai acest tip de SG BD.

O bază de date reprezint ă o colec Ńie de date organizate sub form ă de tabele (în terminologia bazelor
de date, un fi șier se nume ște tabel ă), date între care exist ă anumite leg ături (numite rela Ńii logice), și
care permite c ăutarea rapid ă și reg ăsirea informa Ńiilor utilizând calculatorul. Tabelele sunt organiz ate
pe linii Ți coloane. Coloanele se mai numesc câmpuri (fields ) iar liniile se mai numesc înregistr ări
(records ).

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 17 Utilizarea SBBD-urilor este dat ă de anumite facilit ăȚi, printre care se enumer ă:
/lozenge6 Una din facilit ăŃile care se va g ăsi la majoritatea SGBD-urilor, dar diferit realizat ă de la program
la program, este scrierea aplica Ńiilor (programarea ). Având la dispozi Ńie limbaje de programare
specifice bazelor de date, se pot dezvolta diverse proceduri ce personalizeaz ă cu adev ărat
aplica Ńia respectiv ă. Programele pot fi scrise instruc Ńiune cu instruc Ńiune sau descrise prin
evenimente, pot exista structuri de gen WHILE, FOR, CASE sau nu. Se pot genera în unele
SGBD-uri și fi șierele sau codurile executabile .EXE, ce pot fi de sine st ătătoare ( stand alone ) sau
minimale, adic ă folosesc biblioteci externe cu care se pot lega di namic.
/lozenge6 O alt ă facilitate foarte important ă este s ecuritatea datelor . Se pot proteja astfel, prin parole,
înregistr ări sau fi șiere, grupuri de fi șiere și aplica Ńii. Exist ă diverse nivele de protec Ńie, stabilite în
general, de administratorul bazei de date. În cazul lucrului în re Ńea, securitatea datelor este foarte
important ă. Sunt probleme create de accesul la date partajat sau accesul la date numai pentru
vizualizare și nu pentru modificare sau restructurare. Poate fi protejat ă chiar și intrarea în SGBD,
prin parole pe dou ă sau mai multe nivele.
/lozenge6 Orice aplica Ńie mai serioas ă trebuie prezentat ă într-o form ă cât mai accesibil ă. Acest lucru se
realizeaz ă de obicei, prin ceea ce se nume ște interfa Ńa aplica Ńiei sau meniurile . Meniurile sunt
dialoguri la nivel utilizator prin care se pot sele cta diverse c ăi de urmat în aplica Ńia respectiv ă.
Exist ă în general un generator de meniuri ce scoate în fi nal cod-program, care poate fi legat de
restul p ărŃilor din aplica Ńie. Se pot folosi meniuri Pop-up, Pull-down , butoane radio, de bifare, de
ap ăsare etc., ce pot fi lansate printr-o combina Ńie de taste ( shortcut ) sau selectate cu mouse-ul și
care dau aplica Ńiei o fa Ńă mult mai prietenoas ă și mai ales mai accesibil ă.
/lozenge6 Rela Ńii între fi șiere (join ) sunt necesare în cazul în care nu se dore Țte sau nu se poate s ă se
păstreze informa Ńii complete despre un obiect. Descrierea obiectului , aflat în alt ă tabel ă, poate fi
accesat ă prin stabilirea unei rela Ńii cu aceast ă descriere, evitându-se astfel multiplicarea acelei a și
informa Ńii și inconsisten Ńa informa Ńiei. În bazele de date rela Ńionale aceast ă trimitere se realizeaz ă
printr-o adres ă, un cod. Pot fi stabilite rela Ńii de tipul unu-la-unu ( one to one ) sau unu-la-mul Ńi
(one to many ). Ele pot fi șterse sau modificate în mod interactiv sau descript iv.
/lozenge6 O alt ă problem ă realizat ă în mod diferit de diversele SGBD-uri este cea a im portului și exportului
de fi șiere sau date, adic ă a compatibilit ăŃii . În lumea bazelor de date sunt încet ăŃenite câteva
formate standard de tip xBase , ISAM (Indexed Sequential Access Method) , ceea ce face ca
SGBD-urile s ă poat ă lucra nu numai cu baze de date proprii ci și cu altele. Astfel se pot porta
între ele baze de date dBASE cu FoxPro , Paradox , Access , Informix ; ba chiar exist ă un SGBD
numit Magic care nu are format propriu ci folose ște drivere specifice pentru celelalte baze de
date.
/lozenge6 În fine, o alt ă facilitate a SGBD-urilor este dat ă de existen Ța Help-urilor interactive sau
obi șnuite, ce pot scoate utilizatorul din multe încurc ături. Bazele de date sub Windows ofer ă
suport pentru DDE și OLE (grafic ă, imagine) ce permite elaborarea unor aplica Ńii cu imagine,
sunet și anima Ńie – multimedia .
2.1.4. Programe de prezentare
Programele de prezentare sunt utilizate pentru a co nverti diverse informa Ńii în elemente grafice. Aceste
programe ofer ă capacit ăŃi multimedia (utilizarea de fotografii, anima Ńii, sunete și secven Ńe video) dar
și posibilit ăŃi de a face prezent ări pentru Internet.

Avantaje:
/lozenge6 asigur ă o comunicare simpl ă și sugestiv ă;
/lozenge6 construiesc prezent ări eficiente;
/lozenge6 ofer ă posibilit ăŃi de interactivitate.
Programele de grafic ă s-au dezvoltat uimitor dup ă apari Ńia unei interfe Ńe grafice și a unor pl ăci grafice
puternice, cu posibilitatea definirii unui num ăr mare de culori și forme. Folosesc, în general, mouse-ul,
creioanele optice, uneltele care sunt la dispozi Ńia utilizatorilor Ți sunt afi șate sub forma unor butoane

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 18 pe ecran (creioane, foarfec ă, gum ă, pensule, rolluri, lupe etc.). Dispun de palete de culori prin care se
poate selecta o culoare predefinit ă sau defini o culoare utilizator ( custom ). Genereaz ă formate grafice
specifice, unele de tip bitmap (orientate pe puncte), altele de tip vectorial (orientate pe curbe, linii).

Programele de grafic ă actuale sunt programe orientate pe obiecte grafice , dar mai rezist ă înc ă și
programe de grafic ă orientate ecran. Exist ă în aceast ă lume a graficii, programe de grafic ă utilitar ă
sau de afaceri (Bussines Graphics ) care sunt extrem de preten Ńioase din punct de vedere hardware dar
sunt suficiente de simple în utilizare. Ele sunt do tate cu seturi ample de desene prefabricate ( Clip Art )
și au în general formate vectoriale. Dintre acestea putem aminti: Powerpoint (Microsoft), Freelance
Graphics (Lotus), Corel Presentations (Corel), Pers uasion (Aldus), Charisma (Micrografx).

O a doua categorie o constituie procesoarele de imagini ce sunt utilizate pentru pictur ă, afi șe, colaje,
retu șuri fotografice, anima Ńie, prelucrare video. Prelucr ările oferite de astfel de programe merg de la
reglaje de contraste și luminozitate, efecte speciale de vizualizare și transformare a imaginii, deform ări
plane și spa Ńiale, efecte de posterizare, pân ă la colorarea imaginilor alb-negru, capturi ale ecr anelor,
ad ăugare de perspective și multe altele.

Din aceast ă categorie se poate semnala câteva, men Ńionând c ă toate sunt sub Windows sau sub Mac :
/lozenge6 PhotoShop (Adobe) ;
/lozenge6 PhotoStyler (Aldus) ;
/lozenge6 Picture Publisher , PhotoMagic (Micrografx) ;
/lozenge6 Corel Draw (Corel) ;
/lozenge6 Painter (Fractal Design) ;
/lozenge6 Image Wizard (Image Ware) ;
/lozenge6 Image Pals (ULead).
Programele de prezentare sunt programe de grafic ă, sunet și anima Ńie menite s ă realizeze mult mai
șocant și diversificat prezent ări necesare lans ării unui produs nou, reclame publicitare, clipuri,
instruire asistat ă de calculator etc. Paleta lor este foarte larg ă, mergând de la simple programe de
grafic ă și ajungând la programe multimedia, adic ă programe ce pot lucra cu imagini video, muzic ă,
anima Ńie.
2.1.5. Programe de lucru pe Internet
Între cele mai importante produse software utilizat e în prezent, aflate într-o dezvoltare permanent ă se
afl ă web browser –ele . Netscape Navigator, Internet Explorer sau Opera s unt cele mai r ăspândite
programe care lucreaz ă în Internet și ofer ă accesul la resursele acestuia. Domeniile de utiliz are a lor
sunt:
/lozenge6 navigare în Internet;
/lozenge6 căutare de informa Ńii;
/lozenge6 po ștă electronic ă;
/lozenge6 transferul de fi șiere;
/lozenge6 grupuri de discu Ńi;
/lozenge6 alte aplica Ńii (chat, video-chat, fax).
Po șta electronic ă (e-mail) a schimbat modul de lucru al oamenilor și posibilit ăŃile de comunicare.
Acest sistem permite transmisia și recep Ńia de mesaje în form ă electronic ă (digital ă) prin Internet sau
alte re Ńele. Facilit ăŃile po Țtei electronice sunt:
/lozenge6 transmitere/primirea de mesaje de la/c ătre unul sau mai mul Ńi utilizatori, folosirea de mailing list ;
/lozenge6 confiden Ńialitate și securitate;
/lozenge6 posibilitatea r ăspunsului automat;
/lozenge6 crearea de liste de subscrip Ńie;
/lozenge6 acces la cutia po ștal ă din mai multe locuri;
/lozenge6 transfer de fi șiere (text sau multimedia);

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 19 /lozenge6 filtrarea și sortarea mesajelor primite;
/lozenge6 utilizarea de agen Ńi inteligen Ńi.
2.2. Alte tipuri de produse software
Evident software-ul pentru sistemele informatice nu se opre ște aici. Exist ă un num ăr mare de
programe ce vor fi prezentate în continuare.
2.2.1. Programe utilitare
Programul utilitar este un program mai mic ce aduce îmbun ătăŃiri fa Ńă de lucrul în sistem de operare,
realizând diverse opera Ńii simple sau mai complexe asupra suporturilor de m emorie sau datelor aflate
pe aceste suporturi. Opera Ńiile pe care le fac programele utilitare pot fi rea lizate și direct din sistemul
de operare de c ătre speciali ști, lucrând cu întreruperile, gestionând memoria ma i bine, îns ă ele se
realizeaz ă foarte greu de c ătre un nespecialist. De altfel, apari Ńia programelor utilitare a dus la
dezvoltarea și perfec Ńionarea sistemelor de operare, astfel încât aceste sisteme au integrat treptat și
multe programe utilitare (gen Notepad , Wordpad , Paint etc.).

Facilit ăŃile pe care le-au adus programele utilitare referit or la hard disc au fost legate în primul rând de
posibilitatea de afi șare în regim text sau grafic a structurii pe folder e și subfoldere a acestuia. Afi șarea
sub form ă arborescent ă ( tree ) cu ramifica Ńiile detaliate sau nu, cu rela Ńiile dintre fi șiere și structur ă,
afi șarea în ferestre cu posibilitatea rapid ă de copiere, mutare dintr-o fereastr ă în alta, selectarea
fi șierelor mult mai rapid ă, afi șarea con Ńinutului unui fi șier cu posibilitatea edit ării lui, dac ă
dimensiunea acestuia nu este prea mare, vizualizare a fi șierelor și directoarelor ordonate dup ă diverse
criterii: nume, extensie, lungime, dat ă sunt numai câteva facilit ăŃi pe care le-au adus programele
utilitare. Tot cu aceste programe se mai pot crea m eniuri proprii în care pot fi introduse comenzi
întâlnite frecvent, executarea lor f ăcându-se prin selectarea op Ńiunii din meniu sau prin scurt ături
(shortcuts ). Sunt de fapt primul pas f ăcut spre sistemele de operare vizuale, cu interfe Ńe prietenoase ca
WindowsNT, Macintosh, Next.

Din categoria acestor programe utilitare amintim:
/lozenge6 Norton Desktop (Symantec) ;
/lozenge6 Norton Antivirus (Symantec) ;
/lozenge6 Dashboard (Hewlett-Packard) etc.
Ele aduc și alte facilit ăŃi referitoare la date, fi șiere cum ar fi: protejarea prin parole a fi șierelor,
folderelor, discurilor, compactarea sau arhivarea d atelor pentru a m ări spa Ńiul pe disc, copierea și
ștergerea fi șierelor automat ( backup ) la un anumit moment din zi cur ăŃarea discului și a memoriei de
eventualii viru și. Unele programe utilitare pot reface informa Ńii șterse (fi șiere, foldere) sau pierdute
prin formatare accidental ă, facilit ăŃi numite undelete și unformat . Defragmentarea este o alt ă
opera Ńiune prin care se grupeaz ă spa Ńiul liber de pe disc în mod compact (la început sau la sfâr șit)
astfel încât accesul la un fi șier sau folder s ă fie mult mai rapid ca și c ăutarea unui spa Ńiu liber pentru
crearea unui fi șier sau folder. Gestionarea memoriei mult mai efici ent se poate face prin programe
utilitare, ce pot „m ări” memoria conven Ńional ă de 640 Kb prin utilizarea memoriei de la 640 K în sus
(expanded & extended memory ), astfel încât cantitatea de date ce poate fi prel ucrat ă nemaif ăcându-se
acces la hard-disk cre ște substan Ńial și odat ă cu aceasta timpul de execu Ńie se mic șoreaz ă. Tot pentru
mărirea vitezei exist ă utilitare ce pot anticipa ce parte a discului va f i folosit ă și pot înc ărca în memorie
informa Ńiile din aceast ă zon ă ( chaching ). Probleme de comunica Ńii pot fi rezolvate și ele cu ajutorul
programelor utilitare. Astfel de utilitare sunt:
/lozenge6 Norton Utilities ;
/lozenge6 PCAnywhere (Symantec) ;
/lozenge6 After Dark (Berkeley Sys.) ;
/lozenge6 QEMM (Quarterdeck) ;

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 20 /lozenge6 Fastback (Fifth Generation).
Odat ă cu dezvoltarea platformei Windows au ap ărut utilitare ce pot crea iconuri, cursoare de mous e,
meniuri, dialoguri, acceleratoare etc.
2.2.2. Pachete integrate
Folosirea eficient ă a unui calculator necesit ă cel pu Ńin folosirea unui procesor de texte, unui program
de calcul tabelar, a unei baze de date și eventual a unui procesor de imagine. Cum majorita tea
utilizatorilor au nevoie de câte un program din fie care, multe firme ofer ă pachete con Ńinând fie o
colec Ńie de programe care sunt vândute și separat, fie un produs integrat care ofer ă facilit ăŃile de
procesare de texte, calcul tabelar, grafic ă și baze de date simple.

Acestea se numesc pachete integrate și au avantajul comunicabilit ăŃii între produse, uniformit ăŃii
stilistice și nu în ultimul rând al pre Ńului mai sc ăzut. Dintre acestea se poate aminti:
/lozenge6 MS Office al firmei Microsoft ;
/lozenge6 Smart Suite al firmei Lotus ;
/lozenge6 WordPerfect Office al firmei Corel ;
/lozenge6 Star Office al firmei Sun ;
/lozenge6 Open Office al Open Office Org ;
Aproape toate pachetele integrate ofer ă și programe de comunica Ńii de po ștă electronic ă, organizatoare
etc. și folosesc Windows-ul, ceea ce asigur ă o portabilitate și compatibilitate a aplica Ńiilor dîntr-un
produs în altul.
2.2.3. Proiectare asistată pe calculator
Programele de proiectare asistat ă de calculator CAD ( Computer Aided Design ) sunt programe de
grafic ă, mai preten Ńioase, în care precizia desen ării joac ă un rol foarte important. Se pot proiecta
obiecte tridimensionale asupra c ărora se pot aplica sec Ńion ări, scal ări, rota Ńii, compuneri și
descompuneri de obiecte.

Vizualizarea obiectelor poate fi f ăcut ă în cele mai mici am ănunte și din diverse pozi Ńii. Produsele din
aceast ă categorie dispun de bogate biblioteci grafice, cu multe exemple, cu imagini ce pot fi ad ăugate
în bibliotec ă, cu stiluri de linii, cu pattern-uri pentru ha șuri și suprafe Ńe. Ustensilele de care dispun sunt
ușor accesibile cu ajutorul mouse-ului, se poate folo si cu u șurin Ńă compasul, linia, guma, lupa și multe
altele, printr-o simpl ă ap ăsare a unui buton dintr-o tabel ă de instrumente ( tools ).

Posibilitatea inser ării textului în imagine precum și importul de imagini de tip raster sunt alte facil it ăŃi
ce fac din programele de proiectare o solu Ńie produc Ńiv ă pentru crearea rapid ă de desene, rapoarte,
schi Ńe, documente.

Dintre aceste programe de proiectare asistat ă se remarc ă:
/lozenge6 Auto CAD for Windows, Generic CAD, Auto Sketch (Aut oDesk)
/lozenge6 Drafix CAD (Foresight) ;
/lozenge6 Design CAD 2D/3D (American Design) ;
/lozenge6 Toolbox Professional ;
/lozenge6 Auto Architect etc.
2.2.4. Programe de gestionare a documetelor și de b irou
Programele DMS ( Document Management System ) sunt programe specializate în organizarea și
stocarea documentelor de tip text sau imagine. Exis t ă sisteme DMS destinate în princip al prelucr ării

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 21 de texte prin stocarea lor într-o arhiv ă indexat ă și sisteme DMS destinate prelucr ării de imagini cu
stocarea acestora pe discuri optice.
Într-un sistem DMS se definesc mai întâi profiluril e documentelor, adic ă informa Ńii ce definesc
con Ńinutul unui document, tipul acestuia, cine l-a crea t și când, unde este stocat, leg ături cu alte
documente. Indexarea se poate face dup ă aceste profile sau dup ă cuvinte cheie existente în documente.
Func Ńia principal ă a unui DMS este reg ăsirea rapid ă a documentelor și vizualizarea acestora . Dac ă
specifica Ńiile nu sunt complete atunci se furnizeaz ă lista documentelor ce satisfac condi Ńiile de
interogare, pe baza indexului profilelor sau chiar cuvintelor din documente. Un sistem DMS este
destinat lucrului în re Ńea, deoarece la un document trebuie s ă aib ă acces, eventual în acela și timp, mai
multe persoane precum și faptului c ă un document poate fi realizat de c ătre mai multe persoane. Apar
astfel probleme de actualizare a versiunilor docume ntelor, modific ări ireconciliabile de c ătre persoane
diferite, securitate și control asupra accesului la un document, ce sunt rezolvate în mod diferit de la
program la program.

Calea c ătre biroul f ără hârtii este deschis ă prin aceste DMS, dar ele necesit ă în general un scanner, un
PC puternic, o imprimant ă rapid ă, discuri optice în cazul prelucr ării de imagini, ceea ce poate duce la
un cost destul de ridicat, deocamdat ă! De altfel probleme legate de recunoa șterea optic ă a caracterelor
(OCR), arhivare, dezarhivare rapid ă sunt probleme de actualitate în domeniul DMS și care dau o
imagine fantastic ă viitorului.

Din familia sistemelor DMS se pot remarca:
/lozenge6 Auto EDMS al firmei ACS Telecom ;
/lozenge6 Notes 3.0 al firmei Lotus ;
/lozenge6 Apple Search al firmei Apple ;
/lozenge6 Acrobat al firmei Adobe .
Produsele PIM ( Personal Information Manager ) includ un planificator de activit ăŃi corelat cu un
calendar, o agend ă de adrese, cu posibilitatea de conectare la telefo n prin plac ă de fax sau modem,
notesuri pentru diverse documente, dic Ńionare etc.

Un PIM este un produs u șor de folosit, rapid în utilizare și nu necesit ă un spa Ńiu mare pe disc. Este un
program ce st ă resident în memorie, adic ă poate fi accesat oricând se dore Țte, chiar dac ă este activ un
alt program. Manipularea produsului se face de obic ei cu ajutorul mouse-ului ca de exemplu r ăsfoirea
unor pagini ce apar pe ecran, selectarea unor liter e din repertoar. În prezent multe din func Ńiile acestora
se reg ăsesc în programele de e-mail (Outlook, de exemplu). Acestea pot importa date dintr-o baz ă de
date sau spreadsheets sau interschimba date, inform a Ńii cu un alt utilizator de PIM. Mai poate con Ńine
agende cu c ărŃi de vizit ă, cu organizarea timpului pe zile și ore, având posibilitatea realiz ării unor
leg ături între persoane și notesul cu activit ăŃi sau întâlniri, anun Ńă rii programate în cazul unor
evenimente ca anivers ări, activit ăŃi importante.

Dintre aceste produse se pot remarca:
/lozenge6 Act al firmei Symantec (CSI) ;
/lozenge6 Organizer al firmei Lotus .
Posibilitatea list ării la imprimant ă, în diverse formate standard sau definite de utili zator, a oric ărei
componente a PIM-ului, introducerii parolelor de ac ces, personaliz ării agendei prin nota Ńii proprii,
inser ării de poze și imagini în agend ă sunt și alte facilit ăŃi care fac din PIM instrumentul ce poate
elibera un birou de teancul de hârtii, agende, c ărŃi de vizit ă etc.
2.2.5. Shareware și public domain
Oferta shareware const ă din programe diverse testate sau netestate, dispon ibile la pre Ńuri foarte mici,
cu posibilitatea încerc ării lor înainte de a le cump ăra. Dac ă programul se dovede ște a fi util atunci este
obligatorie virarea unei sume modice în contul auto rului produsului, nu al vânz ătorului, putând primi

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 22 astfel documenta Ńii și versiuni îmbun ătăŃite ale programului respectiv. Pia Ńa produselor shareware
cuprinde practic toate domeniile, cum ar fi: progra me utilitare, jocuri, programe educa Ńionale, aplica Ńii
grafice, limbaje de programare, spreadsheets, proce soare de texte, baze de date etc.

Oferta public domain const ă din produse software la pre Ńuri foarte mici pe care cump ărătorul le poate
da prietenilor sau chiar le poate revinde f ără nici o restric Ńie.

Ce se urm ăre ște prin produsele shareware și public domain ? În primul rând intrarea în „lumea bun ă” a
informaticii, de asemenea promovarea produselor, câ știgarea unui num ăr mare de clien Ńi, virtuali
cump ărători și ai unor alte produse ale acelea și firme (nu obligatoriu tot produse shareware).
2.3. Clasificarea sistemelor informatice
Clasificarea sistemelor informatice se face în func Ńie de anumite criterii, și anume: [Lungu&alt, 1995],
[Oprea, 1999]
1. În func Ńie de domeniul de utilizare , acestea se clasific ă în patru grupe, care sunt prezentate în
urm ătoarea figur ă.

a. Specific sistemelor informatice pentru conducerea activităŃi lor organizaŃiilor
economicoEsociale este faptul c ă datele de intrare, de regul ă, sunt fumizate prin documente
întocmite de om, iar datele de ie șire sunt fumizate de c ătre sistem tot sub form ă de documente
(liste, rapoarte etc.) pentru perceperea acestora d e c ătre om.
b. Spre deosebire de acestea, sistemele informatice pentru conducerea proceselor
tehnologice se caracterizeaz ă prin aceea c ă datele de intrare sunt asigurate prin intermediul
unor dispozitive automate care transmit sub form ă de semnale (impulsuri electronice)
informa Ńii despre diver și parametri ai procesului tehnologic (presiune, tem peratur ă, umiditate,
nivel), iar datele de ie șire se transmit, de asemenea, sub form ă de semnale unor organe de
execu Ńie, regulatoare, care modific ă automat parametrii procesului tehnologic. Se execu t ă în
acest fel controlul și comanda automat ă a procesului tehnologic. Astfel de sisteme sunt
folosite în locurile în care este periclitat ă interven Ńia în mod direct a factorului uman. Exemple
de asemenea sisteme sunt cele pentru laminarea o Ńelului, pentru procesele din petrochimie,
pentru fabricarea cimentului, a hârtiei, centrale n ucleare etc. În mod firesc apar diferen Ńe între
obiectivele celor dou ă categorii de sisteme, cele pentru conducerea proce selor tehnologice
având ca obiective îmbun ătăŃirea randamentului agregatelor, urm ărirea siguran Ńei în
func Ńionare, cre șterea indicatorilor de calitate a produselor, îmbun ătăŃirea altor indicatori
tehnico-economici. SISTEME
INFORMATICE
pentru Conducerea activităŃilor
organizaŃiilor economicoî
sociale
Conducerea proceselor
tehnologice
Cercetare știinŃifică și
proiectare tehnologică
ActivităŃi speciale

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 23 c. Sisteme informatice pentru activitatea de cercetare știinŃifică și proiectare
tehnologică asigur ă automatizarea calculelor tehnico-inginere ști, proiectarea asistat ă de
calculator și alte facilit ăŃi neesare speciali știlor din domeniile respective.
d. Sistemele informatice speciale sunt destinate unor domenii specifice de activitat e, ca
exemplu: informare și documentare, tehnico- știin Ńific ă, medicin ă etc.
2. Un alt criteriu de clasificare al sistemelor inform atice economice este în func Ńie de nivelul
ierarhic ocupat de sistemul economic în structura organizatoric ă a organiza Ńiei, conform c ăruia
avem urm ătoarea clasificare:
a. Sisteme informatice pentru conducerea activităŃii l a nivelul organizaŃiilor economice .
Acestea pot fi descompuse în subsisteme informatice asociate func Ńiunilor organiza Ńiilor
economico-sociale sau chiar unor activit ăŃi.
b. Sisteme informatice pentru conducerea activităŃii l a nivelul organizaŃiilor economicoE
sociale cu structură de grup . În aceast ă categorie sunt incluse sistemele informatice la
nivelul regiilor autonome.
c. Sisteme informatice teritoriale . Sunt constituite la nivelul unit ăŃilor administrativ-
teritoriale și servesc la fundamentarea deciziilor adoptate de c ătre organele locale de
conducere.
d. Sisteme informatice pentru conducerea ramurilor, su bramurilor și activităŃilor la
nivelul economiei naŃionale . Se constituie la nivelul ramurilor, subramurilor și activit ăŃilor
individualizate în virtutea diviziunii sociale a mu ncii și specificate în clasificarea economiei
na Ńionale. Sunt elaborate și administrate de ministerele, departamentele sau o rganele care au
prin lege sarcina de a coordona metodologic grupele respective de activit ăŃi. Principala lor
func Ńie const ă în fundamentarea și reglarea echilibrului dezvolt ării economico-sociale în profil
de ramur ă.
Aceste sisteme vor trebui s ă realizeze elaborarea de variante a proiectului de plan în profil de
ramur ă, înc ărcarea optim ă a capacit ăŃilor de produc Ńie, folosirea intensiv ă a ma șinilor,
utilajelor și instala Ńiilor, urm ărirea și controlul realiz ării sarcinilor de plan și a celor privind
calitatea produc Ńiei, perfec Ńionarea produselor și a tehnologiilor, înnoirea produc Ńiei și
asigurarea de noi produse, utilizarea superioar ă a poten Ńialului material și uman din ramura
respectiv ă.
e. Sisteme informatice funcŃionale generale ce au ca atribut principal faptul c ă intersecteaz ă
toate ramurile și activit ăŃile ce au loc în spa Ńiul economiei na Ńionale, furnizând informa Ńiile
necesare coordon ării de ansamblu și sincroniz ării lor în procesul reproduc Ńiei din cadrul
economiei de pia Ńă . În aceast ă categorie sunt cuprinse sistemele pentru planifica re, statistic ă,
financiar-bancar etc.
3. Un alt criteriu de clasificare al sistemelor inform atice este acela dup ă aportul acestuia în actul
decizional .
Decidentul dintr-o unitate are prin sistemul inform atic un puternic suport pentru fundamentarea
deciziilor sale. Acest suport implementeaz ă modele matematico-economice din domeniul specific
de activitate sau cu caracter general. Este situa Ńia clasic ă de realizare a sistemelor informatice ca
asistent al decidentului. Acestea execut ă o mic ă parte din activitatea decidentului, rolul lor
important fiind de culegere și prelucrare automat ă a datelor. Este perioada de pân ă în jurul anului
1970, când dou ă discipline au venit în sprijinul știin Ńific al sistemului informatic-decizional:
cercet ările opera Ńionale și teoria deciziei. În aceast ă perioad ă apar și primele sisteme suport de
decizie (SSD ) ca sisteme pentru prelucrarea automat ă a datelor împreun ă cu sistemele de luare a
deciziilor.
Anii 1970 au însemnat o cre ștere puternic ă a fluxului informa Ńional în toate domeniile de
activitate, a bazelor de date și a teleprelucr ării. Acestea au permis prelucrarea unui volum mai
mare de date și o comunica Ńie mai rapid ă și mai eficient ă. Rolul sistemului informatic cre ște în
raport cu decidentul, ajungând s ă fie un colaborator al acestuia. De multe ori, aces te sisteme

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 24 informatice execut ă o parte însemnat ă din activitatea decidentului evoluând, astfel spre sisteme
suport de decizie.
Începând cu anii 1970, bazele de date au evoluat sp re rela Ńional și distribuit, iar re Ńelele de
calculatoare locale și generale au devenit curente. Informa Ńia care se prelucreaz ă se diversific ă
foarte mult, volumul de date este tot mai mare, iar complexitatea prelucr ărilor de asemenea.
Sistemele informatice încep s ă execute mare parte din activitatea de rezolvare a problemelor de
decizie, devenind experte în domeniu, evoluând astf el spre sisteme expert ( SE ). Volumul de
date mare și complexitatea deosebit ă a datelor care circul ă pe magistralele (re Ńelele)
informa Ńionale interna Ńionale în momentul de fa Ńă tind s ă sufoce sistemele informatice bazate pe
rela Ńional. Abordarea orientat ă obiect, precum și realizarea de baze de cuno știn Ńe, pe ma șini tot
mai puternice, tind s ă rezolve aceast ă problem ă.
Sistemele expert, precum și sistemele suport de decizie sunt de fapt sisteme informatice dedicate.
Iat ă câteva aspecte comune și deosebiri dintre ele:
a. Tehnologia de realizare se p ăstreaz ă în mare parte pentru toate cele trei tipuri de sis teme. Pe
de o parte, SSD și SE au preluat în metodologia lor de realizare maj oritatea activit ăŃilor din
metodologia de realizare a SI, adoptând o parte din ele. Pe de alt ă parte, metodologia de
realizare a și a evoluat mult odat ă cu apari Ńia SSD și SE, preluând o serie de elemente de
simplitate, flexibilitate, precum și stilul de lucru în pa și m ărun Ńi și relu ări succesive. Ideea ca
un sistem informatic, ca dealtfel orice produs info rmatic, se realizeaz ă "la cheie" prin etape
care odat ă realizate nu se mai pot relua, nu mai este agreat ă. Stilul de lucru de la sistemele
expert care presupune realizarea unei versiuni care nu este nici ultima, nici cea mai bun ă,
urmând apoi s ă se realizeze versiuni succesive pentru perfec Ńionare și dezvoltare, este tot mai
mult utilizat și în realizarea sistemelor informatice.
b. Toate folosesc abordarea sistemic ă pentru studierea și rezolvarea problemelor. Aceasta este o
cale eficient ă pentru învingerea complexit ăŃii și p ăstrarea coeren Ńei.
Abordarea sistemic ă presupune o serie de caracteristici în procesul de cunoa ștere,
caracteristici care se reg ăsesc la realizarea tuturor celor trei tipuri de sis teme. Aceste
caracteristici sunt:
• extragerea sistemului studiat se face din mediul în conjur ător;
• definirea problemei și descrierea ei se face cantitativ și/sau calitativ;
• se definesc mijloacele posibile pentru rezolvarea p roblemei;
• se formuleaz ă diferite variante de rezolvare a problemei;
• se compar ă variantele și se alege cea mai bun ă (cea care satisface cel mai bine cerin Ńele).
c. Modul de rezolvare al problemelor p ăstreaz ă direc Ńii comune care caracterizeaz ă sistemul
uman de prelucrare și evaluare a informa Ńiei. Acest lucru este firesc în SSD și SE, și se
accentueaz ă în și prin abordarea orientat ă obiect. În acest sens, se îmbin ă aspectele descriptive
cu cele imperative, neprocedurale cu cele procedura le, în func Ńie de sistem punându-se
accentul pe unul sau altul dintre aceste aspecte. M odulul rezolutiv se bazeaz ă în special pe
ra Ńionamente, dar și pe algoritmi în SE și se bazeaz ă în special pe algoritmi, date și
ra Ńionamente în SSD și SI. Ra Ńionamentul se bazeaz ă pe modelul logic și nu pe cel fizic, ceea
ce înseamn ă c ă primeaz ă relevan Ńa și mai pu Ńin precizia. Acest lucru este valabil atât în
mecanismul de inferen Ńă din SE, cât și în procesul decizional din SSD. În SI, în modelul
prelucrativ, conteaz ă mai mult precizia și mai pu Ńin relevan Ńa. Aplica Ńiile cu baze de
cuno știn Ńe sunt în ultim ă instan Ńă aplica Ńii informatice care permit rezolvarea de probleme
dificile prin simularea ra Ńionamentului uman asupra unor cuno știn Ńe specifice unui domeniu
dat.
d. Cele trei sisteme, de și au arhitecturi diferite, p ăstreaz ă și elemente comune. Toate au colec Ńii
de date care sunt fi șiere sau baze de date în SI, baze de cuno știn Ńe în SSD (baza de date și
baza de modele) și SE (baza de cuno știn Ńe și modele). În plus fa Ńă de SI, SSD con Ńin o baz ă de
module care este de fapt o bibliotec ă de module permanente sau de uz temporar. Acestea p ot
fi ale utilizatorului sau realizate de firme specia lizate. Modulele operative, tactice sau
strategice, de calcul sau analiz ă etc. Dimensiunile acestor module pot fi de la o si ngur ă rela Ńie
pân ă la foarte multe. Legat de aceast ă baz ă de module, SSD va con Ńine un mecanism de

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 25 construire sau generare a modulelor, va avea posibi litatea s ă restructureze un modul, s ă-l
actualizeze și s ă opereze asupra modulelor pentru a ob Ńine rapoarte de ie șire. În loc de
colec Ńiile de date din SI, SE con Ńin o baz ă de cuno știn Ńe în care se descriu obiectele din lumea
real ă. Ea con Ńine fapte (axiome) și reguli (care pot descrie și modele). Atât SSD, cât și SE au
componente pentru înv ăŃare care achizioneaz ă noi cuno știn Ńe. Aceast ă component ă lipse ște ca
atare în SI, de și sunt încerc ării în acest sens de a fi inclus ă.
De asemenea, toate sistemele con Ńin interfe Ńe cu utilizatorul care tind s ă devin ă tot mai
prietenoase, u șor de folosit și interactive. Aceast ă component ă tinde s ă dep ăș easc ă jum ătate
din codul program generat, în toate cele trei siste me. Tendin Ńa este dat ă de ma șinile interactive
actuale și de societatea informa Ńizat ă care determin ă o utilizare în mas ă a calculatoarelor.
Dialogul dat de interfa Ńă trebuie s ă fie cât mai "natural" pentru a elimina bariera psi hologic ă
dintre om și ma șin ă. Stilul de dialog poate fi întrebare-r ăspuns, limbaj de comand ă, meniu,
videoformat, ferestre etc., la care se adaug ă facilit ăŃile oferite de platformele multimedia (dac ă
acestea sunt disponibile).
e. Toate cele trei sisteme ajut ă decidentul în activitatea sa, îi fundamenteaz ă decizia. Contribu Ńia
fiec ărui tip de sistem la sprijinul decidentului, în fun damentarea deciziilor este prezentat ă în
tabelul 1.1.
Tabelul 1.1. Contribu Ńia fiec ărui tip de sistem la procesul decizional
Tip
sistem Ajutor pentru decident Partea executat ă din activitatea
decidentului
SI
SSD
SE Asistent
Colaborator
Expert O mic ă parte
O parte însemnat ă
O mare parte
f. Problemele rezolvate cu cele trei tipuri de sisteme sunt de natur ă diferit ă, de și au și elemente
comune (provin din lumea real ă etc.) Dac ă într-o problem ă criteriile sunt preponderent
cantitative, iar caracteristicile problemei se form uleaz ă cantitativ, modelarea se face foarte
bine algoritmic și va rezulta un SI. Dac ă îns ă exist ă formul ări mai pu Ńin cantitative se tinde
spre SSD sau SE, care îns ă .nu exclud folosirea algoritmilor. Pentru probleme le complexe în
condi Ńii de incertitudine, se porne ște conceptual, dar și practic, de la baze de date clasice spre
baze de cuno știn Ńe. Acestea au la baz ă cuno știn Ńe incomplete, inconsistente, incerte,
imprecise, ambigui. Pentru fiecare dintre aceste ca tegorii de cuno știn Ńe exist ă o logic ă
nestandard de care se Ńine cont în abordarea problemei. Acest lucru se tra teaz ă bine în SSD și
SE, și foarte greu sau imposibil de tratat în SI.
Din analiza de mai sus rezult ă evolu Ńia în anumite condi Ńii a și spre SSD. La SE evolu Ńia se
constat ă în ceea ce prive ște conceptele (sistem, componente, modele, obiecte etc.),
metodologia de realizare (principalele activit ăŃi, metode, tehnici etc.), solu Ńii software de
implementare (limbaje, tehnici de programare, ingin erie software etc.). Pe de alt ă parte, din
punct de vedere al organiz ării datelor, se constat ă evolu Ńia bazelor de date rela Ńionale spre cele
orientate obiect și spre bazele de cuno știn Ńe. Simplificarea modelului rela Ńional și
îmbun ătăŃirea lui a condus spre modelul orientat obiect. De asemenea, reprezentarea prin
perechile A-V (atribut-valoare) din rela Ńional o reg ăsim și în bazele de cuno știn Ńe (exemplul
din limbajul Prolog).
4. Din punct de vedere al organiz ării datelor sistemele informatice se clasific ă în:
a. SI care au colecŃiile de date organizate în fișiere . Fi șierele pot fi cu organizare clasic ă
(secven Ńiale, indexat-secven Ńiale, relative) sau cu organizare special ă. Acest mod de
organizare a datelor este tot mai rar utilizat ast ăzi, și el este acceptate doar pentru sisteme
mici. În orice caz, aceste sisteme trebuie s ă foloseasc ă și fi șiere care permit accesul direct
pentru u șurin Ńa și rapiditatea manipul ării datelor. În cadrul acestor sisteme informatice datele
se introduc de la tastatur ă în sistemul informatic ori de câte ori este nevoie , creându-se câte un
fi Țier pentru fiecare tip de prelucrare necesar ă sistemului.
b. SI care au colecŃii de date organizate în bază de d ate . Pentru acest lucru se folose ște
un model de date care poate fi arborescent, re Ńea, rela Ńional sau orientat obiect și un SGBD

Proiectarea sistemelor informatice de gestiune
Clasificarea sistemelor informatice E 26 adecvat. Cel mai utilizat model este cel rela Ńional, dar în ultimii ani sunt utilizate din ce în ce
mai mult bazele de date rela Țional obiectuale. Majoritatea și sunt de acest tip datorit ă
avantajelor oferite de bazele de date în crearea și manipularea colec Ńiilor de date.
c. SI mixte care au colecŃii de date organizate în baz ă de date, dar și în fișiere . Pot
ap ărea și astfel de situa Ńii în realizarea unui sistem informatic, în sensul c ă pe lâng ă baza de
date sunt necesare și o serie de fi șiere relativ independente prelucrate din limbaje de
programare, în afara SGBD-ului. Astfel de cazuri ap ar mai ales atunci când se colaboreaz ă cu
alte sisteme sau aplica Ńii informatice (procesoare de text, de imagini, de calcul tabelar, e-mail
etc.).
Aceste criterii nu sunt singurele utilizate în clas ificarea sistemelor informatice. Astfel, alte crite rii au
în vedere:
/lozenge6 Modul de introducere a datelor în sistemul informat ic.
/lozenge6 Modul de prelucrare a datelor generate de sistemele economice.
/lozenge6 Obiectivele urm ărite etc.

Proiectarea sistemelor informatice de gestiune
Stadiul actual și tendinșele dezvoltării sistemelor informatice E 27 Curs 3
Stadiul actual și tendinŃele
dezvoltării sistemelor informatice
În ultimii ani asist ăm la una dintre cele mai importante transform ări din istorie ale infrastructurii
tehnologice a societ ăŃii. Aceast ă schimbare const ă de fapt în ad ăugarea unui nou substrat în
infrastructura tehnologic ă, substrat care este uzual denumit tehnologia informaŃiei . În acest nou
substrat se eviden Ńiaz ă în mod decisiv informatica . Extinderea într-o m ăsur ă din ce în ce mai mare a
tehnologiei informa Ńiei a devenit posibil ă datorit ă progreselor rapide și importante ale
microelectronicii. Aceast ă extindere este pe cale de a produce o schimbare ma jor ă în societatea
noastr ă, și anume, trecerea de la orientarea industrial ă, în care accentul se pune pe ma șin ă și energie, la
o nou ă orientare, informa Ńional ă, în care accentul se pune pe robot și informa Ńie. Este evident c ă și în
continuare ma șina și energia vor juca un rol important, fundamental, î n societatea informa Ńional ă, dar
pentru noile ma șini, pentru noile industrii, ca și pentru celelalte activit ăŃi ale omului, devin esen Ńiale
tehnologiile informatice care au la baz ă electronica, informatica și comunica Ńiile moderne.
[Lungu&alt, 2003]

Informatizarea activit ăŃilor economico-sociale a cunoscut profunde transfor m ări. În cele ce urmeaz ă se
enumer ă câteva din schimb ările și tendin Ńele ce au loc în practica dezvolt ării sistemelor informatice.
1. Se manifest ă în mod clar o tendinŃă spre divizarea costurilor softwareîului sistemelor
informatice . Reducerea costurilor sistemelor informatice se da toreaz ă, pe de o parte, reducerii
costurilor hardware-ului, iar pe de alt ă parte, reducerii costurilor software-ului. În ceea ce
prive ște componenta software, putem spune c ă cu ani în urm ă nu erau a șa de multe produse
software disponibile pe pia Ńă . Modul obi șnuit de implementare a sistemelor informatice era d e a
programa de unul singur software-ul necesar. Fiecar e implementare tindea s ă fie alc ătuit ă din
software-ul pentru un anumit scop. Acest mod de luc ru era extrem de scump pentru c ă nu se
ob Ńineau reduceri de costuri provenite din generalizar ea pe scar ă larg ă a sistemului. Costurile de
proiectare, realizare, men Ńinere și calitate pentru fiecare component ă ar trebui suportate doar de
un singur utilizator al sistemului. În prezent se m anifest ă o tendin Ńă clar ă în dezvoltarea
sistemelor informatice bazate tot mai mult pe platf ormele software de nivel înalt.
O platform ă software corespunde unei platforme de aplica Ńii și con Ńine func Ńii software de baz ă și
func Ńii specifice aplica Ńiei companiei. Prin func Ńiile software de baz ă se definesc și se rezolv ă
problemele comune aplica Ńiei în propor Ńie de circa 80-90%, iar prin software-ul specific
aplica Ńieie se definesc propriet ăŃile comportamentale suplimentare companieie.
O astfel de abordare ofer ă posibilitatea generaliz ării și implement ării sistemelor în mai multe
unit ăŃi economice, cu efecte imediate de divizare și reducere a costurilor pe unitate de
implementare.
Ideea de baz ă a unei platforme comune de aplica Ńii este într-adev ăr veche. Noua inven Ńie este c ă,
în sfâr șit, ideea a ajuns s ă fie implementat ă.
2. Se manifest ă o intensă tendinŃă spre tehnologia sistemelor informa tice bazate pe reŃele de
calculatoare .
Cre șterea complexit ăŃii, variet ăŃii aplica Ńiilor și apari Ńia de noi produse informatice cu un raport
pre Ń/performan Ńă din ce în ce mai avantajos au f ăcut necesar ă și rentabil ă conectarea între ele a
calculatoarelor în cadrul unor re Ńele care constituie la ora actual ă suportul cel mai adecvat pentru
teleinformatic ă.
O importan Ńă remarcabil ă în dezvoltarea re Ńelelor a avut-o Internet-ul (cu semnifica Ńia de re Ńea a
re Ńelelor) care a oferit posibilitatea accesului nelim itat la diverse tipuri de informa Ńii, precum și
comunicarea între diverse persoane de pe întreaga p lanet ă conectate la Internet.

Proiectarea sistemelor informatice de gestiune
Stadiul actual și tendinșele dezvoltării sistemelor informatice E 28 Tendin Ńele din domeniul re Ńelelor de calculatoare cuprind diverse aspecte, cum ar fi apari Ńia și
dezvoltarea de noi protocoale și medii de comunica Ńie ce permit viteze de transport de ordinul
gigabi Ńilor/sec, dezvoltarea f ără precedent a comunica Ńiilor f ără fir, dezvoltarea re Ńelelor de
sateli Ńi, a accesului la distan Ńă în scopul unor opera Ńiuni de comer Ń electronic sau pentru diverse
tranzi Ńii electronice on-line.
3. În domeniul organiz ării datelor se manifest ă tendinŃa spre baze de date orientate obiect .
Structurile clasice de date bazate pe text și valori numerice fie se dovedesc insuficiente, fie
complexitatea lor dep ăș ește posibilit ăŃile de stocare și prelucrare oferite de tehnologiile clasice.
Aplica Ńiile asociate cu disciplinele tehnologice, cum ar f i proiectarea asistat ă de calculator,
sistemele informatice geografice și sistemele bazate cuno știn Ńe, presupun stocarea unor cantit ăŃi
mari de informa Ńii cu o structur ă complex ă. Aceste aplica Ńii necesit ă suport pentru tipurile de date
care nu pot fi reprezentate în sistemele clasice. U nele aplica Ńii informatice solicit ă monitorizarea
unor desene formate din grupuri de elemente complex e ce trebuie s ă fie combinate, separate,
suprapuse și modificate astfel încât s ă permit ă elaborarea unor variante de proiect. Totodat ă,
orientarea spre multimedia aduce elemente noi în lu mea informaticii. Grafica, imaginea
fotografic ă, imaginea video, sunetul, muzica nu pot fi tratate în aceea și manier ă cu a structurilor
tabelare de denumiri și numere.
Dac ă eforturile de extindere a tehnologiilor actuale în domeniul colect ării, stoc ării și prelucr ării
acestor noi tipuri de informa Ńii ca elemente singulare sunt tot mai adesea finali zate cu succes, nu
acela și lucru se poate spune despre administrarea corespu nz ătoare a unor colec Ńii de astfel de
date.
Bazele de date clasice sau rela Ńionale ofer ă prea pu Ńin suport teoretic și practi pentru tipurile
neconven Ńionale de date.
Bazele de date orientate obiect permit crearea de o biecte complexe din componente mai simple,
fiecare având propriile atribute și propriul comportament, în acest fel ele reu șesc s ă ofere solu Ńii
pentru problemele și aplica Ńiile amintite anterior.
4. Sisteme informatice de tip nou .
Pentru aplica Ńiile tradi Ńionale pentru care au fost concepute, sistemele rel a Ńionale satisfac
cerin Ńele acestora. Descrierea datelor sub form ă de tabele corespunde bine tipului de informa Ńii
manipulate de aceste aplica Ńii. O dat ă cu sc ăderea costului calculatoarelor și cre șterea puterii lor
de calcul au ap ărut noi aplica Ńii care manipuleaz ă cantit ăŃi mari de date. Printre acestea
enumer ăm: sisteme pentru proiectarea asistat ă de calculator, sisteme multimedia, sisteme
deschise.
Aceste aplica Ńii exist ă deja și reprezint ă o pia Ńă foarte important ă pentru sistemele de gestiune a
bazelor de date (SGBD). Majoritatea dintre aceste a plica Ńii nu utilizeaz ă îns ă un SGBD, ci sunt
construite cu sisteme dedicate. Acest lucru se dato reaz ă faptului c ă un sistem de gestiune a
bazelor de date rela Ńional SGBDR nu ofer ă func Ńionalit ăŃile necesare. Noile genera Ńii de baze de
date vor trebui s ă Ńin ă cont nu numai de aplica Ńiile tradi Ńionale, dar și de noile aplica Ńii. Utilizarea
unui SGBD standard în locul unui SGBD dedicat va pe rmite reducerea considerabil ă a costului
de punere în func Ńiune a acestor noi aplica Ńii. Este foarte probabil c ă alte tipuri noi de aplica Ńii vor
ap ărea. Din aceast ă cauz ă noile genera Ńii de SGBD vor trebui s ă aib ă implementat conceptul de
extensibilitate. Adic ă ele trebuie s ă fie capabile s ă administreze nu numai tipurile de aplica Ńii
identificate la un moment dat, ci s ă se adapteze la alte tipuri de aplica Ńii care nu au fost prev ăzute
ini Ńial.
a. Sisteme de proiectare asistată de calculator . Aplica Ńiile genereaz ă un ansamblu de faze
(activit ăŃi) pentru realizarea unui produs. Datele manipulate sunt adesea foarte complexe,
descrierea unei componente fiind dependent ă în mare m ăsur ă de celelalte componente ale
aceluia și produs. Se reg ăse ște aici și o parte important ă a informa Ńiei de tip reg ăsire
documentar ă.
b. Sisteme multimedia . Aplica Ńiile de acest nou tip au drept caracteristic ă aceea c ă
administreaz ă datele într-un mod netradi Ńional. Exemplele cele mai cunoscute sunt aplica Ńiile
care administreaz ă imagini și sunet pe lâng ă text și grafic ă. Exist ă deja acum aplica Ńii
comerciale care folosesc astfel de date, cum ar fi, de exemplu, aplica Ńiile meteorologice. Acest

Proiectarea sistemelor informatice de gestiune
Stadiul actual și tendinșele dezvoltării sistemelor informatice E 29 tip de aplica Ńii se caracterizeaz ă printr-un volum foarte mare de date tratate. Imagi nile sunt
date foarte voluminoase care necesit ă un suport de stocare și prelucrare performant.
Tehnologia discurilor optice numerice este adaptat ă acestor aplica Ńii. Un SGBD care suport ă
aplica Ńii multimedia trebuie s ă foloseasc ă tratamentul clasic asupra imaginilor și s ă
administreze leg ăturile de tot felul dintre acestea De exemplu, într -o aplica Ńie meteorologic ă
trebuie c ăutate printre imaginile stocate pe toate cele care ajut ă la detectarea unui ciclon.
Pentru o astfel de opera Ńie trebuie folosit ă tehnica de c ăutare și acces classic într-o baz ă de
date, precum și tehnica specific ă de tratare a imaginilor. Acelea și observa Ńii sunt valabile și
pentru tehnica specific ă de tratare a sunetului. Pentru aplica Ńiile multimedia este deci nevoie
de o integrare tehnologic ă nou ă cu cea tradi Ńional ă.
c. Sisteme deschise . Expresia „sisteme deschise” corespunde ea îns ăș i unui concept vag. Ideea
este de a aduce un plus de flexibilitate organiza Ńiilor prin aplica Ńiile care se dezvolt ă pentru
ele.
Suple Ńea (flexibilitatea) în dezvoltarea și exploatarea sistemelor aferente unei unit ăŃi se
realizeaz ă prin:
• paleta larg ă de diferite tipuri de periferice și platforme ce pot fi interconectate;
• ușurin Ńa de utilizare a instrumentelor de proiectare a sis temelor deschise;
• posibilitatea interconectarii aplica Ńiilor cu alte aplica Ńii dezvoltate pentru platforme
diferite.
La sistemele deschise totul începe cu problema stan dardelor. Anumite standarde sunt stabilite
de comitete na Ńionale și interna Ńionale, altele sunt impuse de grupurile de propriet ari sau
vânz ători, altele exist ă pur și simplu pentru anumite produse care sunt larg util izate (exemplu:
o versiune standard de C a fost acceptat ă de un comitet interna Ńional, MOTIF este o interfa Ńă
promovat ă de un grup de ofertan Ńi încercând s ă normalizeze Unix, Windows este un produs
impus de proprietar – Microsoft etc.). Standardele proprietarilor sau produc ătorilor sunt
acceptate mai u șor dac ă produsul ofer ă facilit ăŃi de interconectare cu alte produse standard
(exemplu: limbajul standard de reg ăsire din bazele de date – SQL).
Pentru a se evalua nivelul de deschidere al unui pr odus informatic și a decide dac ă acesta
poate fi considerat un instrument pentru elaborarea de aplica Ńii acesta trebuie s ă aib ă anumite
caracteristici. Singurele instrumente cu adev ărat dechise sunt limbajele de programare.
d. Sisteme pentru comerŃul electronic . Ca urmare a extinderii Internet-ului, se manifest ă un
interes deosebit pentru o serie de noi aplica Ńii dintre care comer Ńul electronic ocup ă un loc
însemnat.
Comer Ńul electronic presupune o metodologie modern ă care se adreseaz ă folosirii tehnologiei
informa Ńiei ca un poten Ńial esen Ńial al afacerii. În contextul în care Internet-ul p oate fi privit ca
un univers informa Ńional, comer Ńul electronic apare ca un nou mare orizont și trebuie doar s ă
se Țtie modalit ăȚ ile de valorificare deplin ă a acestui poten Ńial.
De și comer Ńul electronic este mai mult ca niciodat ă o problem ă de afacere strategic ă, viitorul
afacerii va depinde de abilitatea de a folosi inter schimbul electronic de date.
Sintetizând se poate spune c ă tendin Ńele în dezvoltarea software sunt:
1. Dezvoltarea de aplica Ńii, pachete integrate ieftine și care se pot utiliza în mai multe domenii.
2. Pachete software care utilizeaz ă resursele de re Ńea, permit conlucrarea la acelea și documente.
3. Integrarea software-ului cu Internet-ul.
4. Programe u șor de utilizat ce folosesc tehnologii obiectuale or ientate grafic, inteligen Ńa artificial ă
în scopul de a utiliza limbajul natural pentru a u șura programarea.
5. Dezvoltarea de exper Ńi-asisten Ńi în cadrul sistemelor expert ce înglobeaz ă inteligen Ńa artificial ă.

Proiectarea sistemelor informatice de gestiune
Stadiul actual și tendinșele dezvoltării sistemelor informatice E 30 3.1. EvoluŃia sistemelor informaŃionale
în cadrul firmelor
În ultimele cinci decenii s-au înregistrat schimb ări semnificative (tabelul nr. 1) în configura Ńia
structurilor informa Ńionale ale firmelor care au devenit în ultima perio ad ă de timp mai
informa Ńizate.[Nistor&alt, 2003]

Pân ă în anii 1960, rolul sistemelor informa Ńionale era simplu: utilizarea lor pentru înregistra rea
opera Ńiunilor legate de func Ńiuni critice și de procesare a tranzac Ńiilor. La sfâr șitul anilor 1960 apare
conceptul de sistem informa Ńional managerial, care se va transforma cu timpul î n sistem informatic
managerial. Rolul acestuia era de a furniza rapoart e predefinite managerilor, rapoarte care con Ńineau
informa Ńiile de care aveau nevoie în fundamentarea deciziilor.
Tabelul nr.1
Func Ńii Atribu Ńii tehnice Control managerial Inima ac Ńiunilor institu Ńionale
Perioada 1950 1960-1970 1980-1990
În perioada 1970-1980 s-a remarcat c ă rapoartele predefinite furnizate de sistemele info rma Ńionale
manageriale ( Management Information System – MIS ) erau insuficiente managerilor pentru luarea
deciziilor, în condi Ńiile în care au intervenit schimb ări semnificative în condi Ńiile de mediu, inclusiv la
nivelul pie Ńelor de referin Ńă . Astfel a ap ărut conceptul de sisteme suport a deciziilor ( Decision Suport
Systems – DSS ). Aceste sisteme ofereau utilizatorilor finali, în special managerilor, un suport
interactiv în procesul de luare a deciziilor. În pl us, aceste sisteme erau mai bine adaptate diferitel or
stiluri manageriale.

În perioada 1980-1990 s-au eviden Ńiat noi roluri ale sistemelor informa Ńionale. Aceast ă perioad ă este
caracterizat ă de dezvoltarea microcalculatoarelor, a pachetelor de aplica Ńii software, și a re Ńelelor de
telecomunica Ńii. Acum, utilizatorii finali pot folosi resursele informa Ńionale ca suport necesar
îndeplinirii sarcinilor, în loc s ă a ștepte un suport indirect al serviciilor informatice din cadrul
departamentelor.

S-a constatat c ă majoritatea managerilor nu utilizau în mod direct nici rapoartele furnizate de sistemele
informa Ńionale manageriale (MIS), nici modelele analitice d e suport a deciziilor furnizate de sistemele
suport a deciziilor (DSS). Astfel a ap ărut conceptul de sisteme informatice executive ( Executiv
Information System – EIS ). Aceste sisteme informatice furnizeaz ă managerilor informa Ńiile critice
exact cum le doresc ace știa și în formatul pe care îl prefer ă.

Tot în aceast ă perioad ă și în special la sfâr șitul anilor 1980 au ap ărut și s-au dezvoltat aplica Ńii ale
inteligen Ńei artificiale în procesele de afaceri și astfel au ap ărut sistemele expert pentru afaceri
(Business Expert System – BES). Ast ăzi, sistemele expert joac ă rolul de consultan Ńi în problemele de
natur ă economic ă a oric ărei firme.

Ultimul deceniu al mileniului este caracterizat de dezvoltarea sistemelor informatice strategice
(Strategic Information System – SIS ). Acestea joac ă un rol direct în ob Ńinerea avantajului
competitiv al unei firme. Modelul lui Michael Porte r a stat la baza cre ării a numeroase astfel de
sisteme informatice strategice. Firmele de ast ăzi trebuie s ă se bazeze pe tehnologia informa Ńiei pentru
a fi competitive pe pie Ńe puternic concuren Ńiale.

În cadrul unei firme se pot întâlni șase tipuri de sisteme informatice structurate pe 4 nivele:
1. Nivelul strategic – acestui nivel îi corespunde sis temul informatic executiv, EIS.
2. Nivelul tactic – la acest nivel se reg ăsesc sistemul suport al deciziilor, DSS, și sistemul
informatic managerial, MIS.

Proiectarea sistemelor informatice de gestiune
Stadiul actual și tendinșele dezvoltării sistemelor informatice E 31 3. Nivelul de cuno știn Ńe – sistemul bazat pe cuno știn Ńe, Knowledge Based System – KBS .
4. Nivelul opera Ńional – se reg ăsesc sistemul de automatizare a activit ăŃilor din birouri ( Office
Automation System – OAS ) și sistemul de procesare a tranzac Ńiilor ( Transaction Processing
System – TPS ).
3.2. Sisteme integrate pentru firme
Schimb ările tot mai rapide în mediul de afaceri și cresterea complexit ăŃii activit ăŃilor din cadrul unei
firme necesit ă o adaptare permanent ă, într-un ritm alert, care adeseori pune la încerca re capacit ăŃile
de efort și analiz ă ale factorului uman. Sistemele / aplica Ńiile integrate au fost create ca solu Ńii la
aceste provoc ări, fiind capabile s ă proceseze volume mari de date și informa Ńii agregate în scopul
optimiz ării și eficientiz ării proceselor.

Un sistem integrat de aplica Ńii pentru întreprinderi este o solu Ńie software complex ă, de nivel înalt,
multi-modular ă, ale c ărei elemente sunt integrate într-o platform ă comun ă, care ofer ă suport pentru
gestiunea resurselor și coordonarea diferitelor procese dintr-o firm ă în vederea realiz ării obiectivelor
de afaceri. Solu Ńia caut ă s ă modernizeze, s ă integreze procesele economice, s ă sincronizeze func Ńiile
întreprinderii și s ă coordoneze alocarea resurselor. De asemenea, virtu al, permite extinderea firmei
dincolo de limitele sale fizice: spre furnizori, cl ien Ńi și parteneri.

În practic ă aceste sisteme de aplica Ńii se reg ăsesc sub diferite denumiri: ERP, SCM, CRM, PLM, BI etc.

În continuare sunt descrise o serie de tipuri mai i mportante de aplica Ńii:
/lozenge6 ERP ( Enterprise Resource Planninng ) – în sens restrâns se refer ă la aplica Ńiile pentru planificarea și
urm ărirea proceselor de produc Ńie, cu luarea în considerare a materialelor, proces elor
tehnologice și resurselor (ma șini, utilaje) disponibile. Actualmente, no Ńiunea de ERP este adesea
utilizat ă în sens larg, pentru a desemna sistemele integrate pentru întreprinderi. În acest sens, un
sistem ERP poate include ca module celelalte tipuri de aplica Ńii men Ńionate.
/lozenge6 SCM ( Supply Chain Management ) – se refer ă la gestiunea lan Ńului de aprovizionare din punct de
vedere al planific ării cantit ăŃilor de produse transferate și stocate între "verigile" unui astfel de lan Ń
– furnizori de materii prime, produc ători, distribuitori și clien Ńi. Se urm ăresc astfel optimiz ări pentru
întregul lan Ń, în locul optimiz ărilor locale ale fiec ărei întreprinderi. Func Ńionarea unui astfel de lan Ń
de aprovizionare presupune rela Ńii de parteneriat între întreprinderi, care s ă faciliteze integrarea
solu Ńiilor software ale acestora, exemplul tipic fiind i ndustria construc Ńiei de automobile.
/lozenge6 CRM ( Customer Relations Management ) – sunt aplica Ńii care sprijin ă implementarea unei
strategii de orientare spre client, prin gestiunea unitar ă a tuturor proceselor ce presupun
interac Ńiunea cu clientul: vânzari, servicii de garan Ńie și post-garan Ńie (callcenter / support) etc. Pot
fi incluse și procese analitice, precum analiza portofoliului d e clien Ńi și a comportamentului
acestora, crearea campaniilor de marketing pe anumi te grupuri Ńint ă etc.
/lozenge6 BI ( Business Intelligence ) – sunt aplica Ńii destinate proceselor de decizie de nivel înalt a le
întreprinderii. Aplica Ńiile de acest tip realizeaz ă colectarea și agregarea datelor tranzac Ńionale
(referitoare la derularea proceselor întreprinderii ), pe baza unui sistem de indicatori de
performan Ńă . Bazate pe tehnologii de tip Data Warehouse/OLAP, aceste aplicatii permit analize
detaliate ale datelor pentru identificarea tendin Ńelor de evolu Ńie și a cauzelor acestora. Prin
instrumente vizuale panou de bord, se pot urmari pe rformantele întreprinderii, cuantificate prin
indicatorii de performan Ńă , fiind indicate și abaterile acestora de la valorile planificate.
/lozenge6 PLM ( Product Lifecycle Management ) – se refer ă la procesele de gestiune a ciclului de via Ńă al
produselor și serviciilor, trecând prin etapele de concep Ńie, proiectare, produc Ńie, service și
retragere. Prin gestiunea unitar ă a datelor despre produse se urm ăre ște accelerarea lans ării
produselor (time-to-market), îmbun ăta Ńirea calit ăŃii și sc ăderea costurilor.

Proiectarea sistemelor informatice de gestiune
Stadiul actual și tendinșele dezvoltării sistemelor informatice E 32 3.2.1. Enterprise Resource Planning
Scopul sistemelor ERP
Sistemul de gestiune integrat ă a proceselor de afaceri are drept scop integrarea și ordonarea informa Ńiei,
realizarea unei mai bune comunic ări de date/informa Ńii în firm ă, prin fluidizarea schimbului de date
între departamente, îmbun ătăŃirea cooper ării și interac Țiunii dintre diverse compartimente și asistarea
procesului de management de nivel superior.

Functionalit ăŃile unui ERP
Modulele unui ERP acoper ă mai multe domenii de interes ale unei afaceri:
/lozenge6 Financiar-contabil.
/lozenge6 Mijloace fixe.
/lozenge6 Planificarea produc Ńiei.
/lozenge6 Gestiunea stocurilor.
/lozenge6 Gestiunea achizi Ńiilor.
/lozenge6 Gestiunea rela Ńiilor cu clien Ńii.
/lozenge6 Gestiunea resurselor umane.
/lozenge6 Managementul calit ăŃii.
/lozenge6 Managementul proiectelor.
/lozenge6 Managementul lan Ńurilor de aprovizionare.
/lozenge6 Managementul ciclului de via Ńă al produselor.
/lozenge6 Analiz ă și suport decizional.
Caracteristicile unui ERP
Fiind o solu Ńie software integrat ă, un sistem ERP trebuie s ă aib ă câteva caracteristici cheie:
/lozenge6 Adaptabilitate – Func Ńionalitatea standard a aplica Ńiilor poate fi modificat ă conform cerin Ńelor
specifice ale întreprinderii utilizatoare, de regul ă în procesul de implementare a unui ERP.
Realizarea adapt ărilor este posibil ă prin configurare (parametrizare, setare, customizing ) care
presupune modificarea unor structuri de date sau pa rametri de sistem; modific ări mai importante
pot necesita modificarea / dezvoltarea codului apli ca Ńiei. În al doilea caz apare dezavantajul ca
procesul de actualizare ( update ) devine mai complicat, deoarece modific ările de cod trebuiesc
refacute dup ă aplicarea pachetelor de actualizare ale producator ului.
/lozenge6 Generalitate – s ă poat ă cuprinde și s ă satisfac ă cele mai multe tipuri de organiza Ńii, s ă suporte
mai multe func Ńii organiza Ńionale; generalitatea și puterea de a sustine organiza Ńii mari și
complexe coexista cu flexibilitatea specifica organ iza Ńiilor mici. Func Ńionalitatea general ă se
refer ă la informa Ńizarea proceselor aplicabile oric ărei organiza Ńii, de ex. contabilitate, resurse
umane, aprovizionare etc. Oferta de aplica Ńii de întreprindere cuprinde și solu Ńii specifice
anumitor domenii de activitate, cum ar fi s ănătate, telecomunica Ńii, comer Ń cu am ănuntul (retail),
industrie aeronautic ă, administra Ńie public ă etc.
/lozenge6 Modularitate – s ă aib ă o structur ă modular ă și orice modul s ă poat ă fi inclus sau deta șat de câte
ori este nevoie f ără a afecta celelalte module sau întreaga structur ă; toate modulele sistemului
sunt strâns legate între ele to Ńi utilizatorii lucrând simultan asupra acelora și date, prin re Ńeaua de
calculatoare, în func Ńie de atribu Ńiile pe care le au.
/lozenge6 Sistem deschis – s ă aib ă o arhitectura de sistem deschis, s ă ofere facilitate care s ă permit ă
integrarea cu alte aplica Ńii deja existente și/sau tranzi Ńia cu eforturi și costuri minime de la alte
module ale aplica Ńiei; s ă ofere un mediu de dezvoltare și documentare pentru utilizatori avansa Ńi
care preiau p ărŃi din între Ńinerea, adaptarea, extinderea sistemului, dar și integrarea cu platforme
și tehnologii de ultim ă or ă cum sunt Web/Intranet/Internet/Data Warehouse.
/lozenge6 Interfa Ńă cu utilizatorul standardizat ă – Modul de operare este unitar, prin standardizare a
design-ului formularelor, a meniurilor aplica Ńiilor și a regulilor de operare. În acest mod este
facilitat procesul de înv ăŃare pentru utilizatori.

Proiectarea sistemelor informatice de gestiune
Stadiul actual și tendinșele dezvoltării sistemelor informatice E 33 /lozenge6 Securitatea datelor – s ă permit ă accesul la date în condi Ńii de securitate deosebite numai în
conformitate cu drepturile acordate fiec ărui utilizator; siguran Ńă și securitatea datelor sunt
asigurate la un nivel deosebit prin sistemul de dre pturi de acces.
/lozenge6 Conectivitate – s ă nu fie limitat la grani Ńele organiza Ńionale ale companiei ci s ă suporte
conectivit ăŃi cu alte module de afaceri din alte companii.
/lozenge6 Simularea realitatii – s ă permit ă simularea proceselor de afaceri reale și s ă poat ă atribui
responsabilit ăŃi utilizatorilor care controleaz ă sistemul.
Pe lâng ă aceste caracteristici generale trebuie remarcat fa ptul c ă un ERP trebuie s ă aib ă o colec Ńie a
celor mai bune procese de afaceri și practici de afaceri, pe care s ă le ofere utilizatorilor.

Avantaje și limite ale utilizarii sistemelor ERP
Avantaje:
/lozenge6 asigur ă informa Ńii on-line și în timp real pentru toate ariile func Ńionale ale unei companii;
/lozenge6 informa Ńia este introdus ă în sistem o singur ă dat ă într-o singură baz ă de date ceea ce asigur ă
acurate Ńea și standardizarea datelor și elimin ă redundan Ńele;
/lozenge6 îmbun ătăŃește accesul la date în vederea lu ării deciziilor în timp util pentru a sus Ńine deciziile de
afaceri;
/lozenge6 diminuarea timpilor de r ăspuns c ătre client dar și la opera Ńiile de afaceri realizate – furnizeaz ă
instrumente de raportare managerial ă divesificate ceea ce îmbun ătăŃește controlul proceselor de
afaceri de c ătre conducerea companiei;
/lozenge6 îmbun ătăŃește procesele de afaceri deoarece oblig ă la utilizarea “celor mai bune practici” ce sunt
incluse în aplica Ńii;
/lozenge6 faciliteaz ă companiilor mari s ă acopere toate domeniile func Ńionale;
/lozenge6 asist ă activit ăŃile cele mai importante din companie și constituie, din acest motiv, o solu Ńie din
cele mai bune pentru management;
/lozenge6 conduce la integrarea complet ă a aplica Ńiilor nu numai între departamentele unei companii c i și
între mai multe companii;
/lozenge6 elimin ă cele mai multe probleme ale unei afaceri: criza ma teriilor prime, sporirea produc Ńivit ăŃii,
livrarea prompt ă, calitatea produselor etc.;
/lozenge6 reduce golurile de informa Ńii din organiza Ńie și ofer ă un flux al informa Ńiilor sigur și f ără
redundante faciliteaz ă introducerea celor mai noi tehnologii (Internet, I ntranet, Videoconferin Ńe,
E-Commerce, EFT – Electronic Fund Transfer, EDI – E lectronic Data Interchange etc.);
/lozenge6 ofer ă o perspective global ă asupra a ceea ce se întâmpl ă în cadrul structurii organiza Ńionale,
asupra cerin Ńelor actuale ale companiei dar și oportunit ăŃi pentru îmbun ătăŃirea continu ă și
rafinarea proceselor de afaceri;
/lozenge6 asigur ă companiei avantaje competi Ńionale și îmbun ătăŃește imaginea companiei;
/lozenge6 îmbun ătăŃește serviciile c ătre clien Ńi și prin aceasta se îmbun ătăŃește imagine companiei.
Limite ale utilizarii ERP:
/lozenge6 durata relativ mare a implement ării;
/lozenge6 costurile implement ării: cheltuiala pentru achizi Ńionare, costuri suplimentare/ascunse (instruire,
inegrare, testare, între Ńinere, adaptare, conversia datelor din sisteme vech i, consultan Ńă );
/lozenge6 amplificarea problemelor de securitate.
3.2.2. Supply Chain Management
În anii 1990 câ Ńiva autori au încercat s ă pun ă esen Ńa SCM într-o singur ă defini Ńie. Ea con Ńine:
/lozenge6 obiectivele teoriei de management;
/lozenge6 grupul Ńint ă;
/lozenge6 obiectiv-ul (ele);
/lozenge6 mijloacele pentru atingerea obiectivelor.

Proiectarea sistemelor informatice de gestiune
Stadiul actual și tendinșele dezvoltării sistemelor informatice E 34 Obiectivul SCM este în mod evident “suplly chaine”, care reprezint ă o re Ńea de organiza Ńii ce sunt
implicate prin leg ături amonte și aval, în diferite procese și activit ăŃi care produc valori sub forma
produselor și serviciilor ce ajung la consumatorii finali.

Într-un sens mai larg un SCM const ă din dou ă sau mai multe organiza Ńii separate legal, dar unite prin
fluxuri de materiale, financiare și informa Ńii. Aceste organiza Ńii pot fi firme ce produc p ărŃi
componente și produse finite, firme ce asigur ă logistica și chiar clientul final însu și.

O re Ńea uzual ă nu se concentreaz ă numai pe fluxurile dintr-un singur lan Ń, ci exist ă fluxuri de lucru
divergente și convergente într-o re Ńea complex ă ce rezult ă din mai multe ordine date de diferi clien Ńi
care trebuie realizate (deservite) în paralel. Pent ru a u șura complexitatea o organiza Ńie dat ă se poate
concentra numai pe o parte din SCM general. Ca un e xemplu privind în aval imaginea unei organiza Ńii
poate fi limitat ă de clien Ńii clien Ńilor ei, iar în amonte de furnizorii furnizorilor e i.

Într-un sens restrâns termenul de SCM este de aseme nea aplicat unei companii mari care are câteva
sedii adesea localizate în Ńă ri diferite. Coordonarea fluxurilor de materiale, i nforma Ńii și financiare într-
o astfel de companie multina Ńional ă într-un mod eficient r ămâne o sarcin ă formidabil ă. Oricum luarea
deciziilor trebuie s ă fie u șoar ă, deoarece aceste puncte fac parte dintr-o singur ă organiza Ńie mare cu un
singur nivel de management. Un SCM în acest sens es te numit și SCM interorganiza Ńional, în timp ce
termenul intraorganiza Ńional se refer ă la SCM. În sens restrâns, f ără a Ńine seama de aceste diferen Ńe
între diferite unit ăŃi func Ńionale ca marketing, produc Ńie, aprovizionare, logistic ă și finan Ńe este
necesar ă o strâns ă colaborare, acesta fiind condi Ńia esen Ńial ă și fireasc ă în firmele de ast ăzi.

Obiectivul care guverneaz ă toate eforturile într-un SCM este cre șterea competitivit ăŃii. Aceasta
deoarece în ochii consumatorului final nu este resp onsabil ă o singur ă unitate organizatoric ă pentru
competivitatea produselor și serviciilor ei, ci SCM ca un întreg. Deci competi tivitatea a fost luat ă și
ridicat ă de la o singur ă companie la un SCM. Evident convingerea unei compa niei individual ă s ă
devin ă parte dintr-un SCM necesit ă o situa Ńie de succes pentru fiecare participant, la un drum lung de
curs ă lung ă, în timp ce aceasta nu se poate implica pentru toa te p ărŃile într-o curs ă scurt ă. Un
impediment general acceptat în îmbun ătăŃirea complexit ăŃii este asigurarea unui service superior
clien Ńilor.

Ca alternativ ă o firm ă poate s ă-și cresc ă competivitatea prin asigurarea unui service genera l, acceptat
la un cost minim. Sunt dou ă c ăii principale de îmbun ătăŃire:
/lozenge6 una este o mai apropiat ă integrare a organiza Ńiilor și închiderea integral ă a organiza Ńiilor
insolvabile,
/lozenge6 a doua este o mai bun ă coordonare a fluxurilor materiale, informa Ńionale și financiare.
Dep ăș ind barierele organiza Ńionale, alinierea strategiilor și gestionarea lan Ńului de aprovizionare sunt
subiecte comune în acest sens. Se va defini termenu l de management al lan Ńului de aprovizionare ca
fiind sarcina de a integra unit ăŃile organiza Ńionale de-a lungul unui lan Ń de aprovizionare, de a
coordona materialele, informa Ńiile și fluxurile financiare pentru a acoperi cererile cl ientului, cu scopul
de a îmbun ătăŃi competitivitatea lan Ńului de aprovizionare ca un tot.
3.2.3. Customer Relationship Management
CRM-ul este un proces care ajut ă la o mai bun ă în Ńelegere a nevoilor și comportamentului clien Ńilor.
El ajut ă la dezvoltarea și la trasarea strategiilor de afaceri pentru client și de asemenea abordeaz ă
problemele prin implementarea lor. În termeni simpl i utilizarea eficient ă a unui CRM ajut ă clientul și
organiza Ńia acestuia s ă îndeplineasc ă acele Ńeluri mult dorite, acele Ńinte referitoare la poten Ńialele
performan Ńe, achizi Ńii, cre șterea și p ăstrarea afacerii. O baz ă de date centralizat ă furnizeaz ă
informa Ńiile despre clien Ńi și asigur ă coordonarea echipelor de marketing, vânz ări și suport.

Proiectarea sistemelor informatice de gestiune
Stadiul actual și tendinșele dezvoltării sistemelor informatice E 35 Un sistem eficient de CRM are drept scop gestionare a și optimizarea ciclului de via Ńă al clientului dar
și construirea unei în Ńelegeri corespunz ătoare sau a unei leg ături între diverse departamente, for Ńe de
vânz ări și clien Ńi în cadrul unor companii mari, care în final toate la un loc vor spori produc Ńia
companiei.

CRM (Managementul Rela Ńiei cu Clien Ńii) este o strategie comercial ă care urm ăre ște stabilirea unei
rela Ńii profitabile și de lung ă durat ă cu clien Ńii. Ast ăzi, CRM este introdus în majoritatea companiilor
mari. Managementul informa Ńiei este sus Ńinut și cuno știn Ńele companiei sunt p ăstrate.

Prin folosirea CRM-ului, o organiza Ńie poate folosi înregistr ările anterioare ale poten Ńialilor clien Ńi și
cump ărători precum și tendin Ńele anterioare de achizitie, tendin Ńe care le-au preferat mai devreme dar
și nevoile acestora, pentru a crea un centru al clie n Ńilor și un sistem de marketing central referitor la
nevoile clien Ńilor.

Companiile care utilizeaz ă sisteme CRM se pot a ștepta imediat:
/lozenge6 la p ăstrarea și ob Ńinerea mai multor clien Ńi, în consecin Ńă la o cre ștere global ă;
/lozenge6 la cre șterea și maximizarea absolut ă a ciclurilor de via Ńă a clien Ńilor;
/lozenge6 la îmbun ătăŃirea serviciilor pentru clien Ńi prin personalizarea acestora;
Succesul unei aplica Ńii CRM const ă în continua dezvoltare a acestuia, pentru a satisf ace noile nevoi și
cerin Ńe ale utilizatorilor acestuia. Este foarte importan t ca utilizatorul de CRM s ă înteleag ă c ă succesul
unei astfel de aplica Ńii const ă în continua dezvoltare și modelare a func Ńiilor aplica Ńiei dup ă nevoile
sale.
3.2.4. Business Intelligence
Luarea deciziilor bune în afacerile care sunt f ăcute este la fel de important ca și în via Ńa particular ă. În
fiecare zi trebuie s ă se ia decizii care s ă determine direc Ńia și eficien Ńa activit ăŃilor dintr-o organiza Ńie.
Se iau decizii în legatur ă cu produc Ńia, marketingul, personalul etc. Deciziile luate af ecteaz ă costurile,
vânz ările, profitul etc. Ca și în via Ńa personal ă, cheia pentru succesul organiza Ńiei este în modul în care
se ia deciziilor. Organiza Ńiile trebuie s ă ia decizii eficiente.

Cine ia deciziile?
La prima vedere, se poate spune ca doar persoanele din varful ierarhiei (CEO, director, pre ședinte)
trebuie s ă ia decizii eficiente care s ă aduc ă succesul în organiza Ńie. Planurile eficiente dezvoltate de
conducerea organiza Ńiei pot e șua datorit ă deciziilor gre șite luate de c ătre persoane din p ărŃile inferioare
ale ierarhiei în procesul de implementare sau în ce l de executie. În concluzie, decizii eficiente treb uie
luate de to Ńi cei din organiza Ńie. Deciziile eficiente luate la fiecare nivel al o rganiza Ńiei duc c ătre
succes.

Ce sunt deciziile eficiente?
Deciziile eficiente sunt acele alegeri care duc org aniza Ńia mai aproape de obiectivele stabilite în timp
util. Dac ă se ia în considera Ńie defini Ńia de mai sus se poate observa trei componente impo rtante care
ajut ă personalul de decizie din cadrul organiza Ției să ia decizii eficiente:
/lozenge6 stabilirea obiectivelor;
/lozenge6 stabilirea unor m ărimi de m ăsurat pentru stabilirea abaterii de la obiective;
/lozenge6 stabilirea termenelor în care trebuie atinse obiect ivele.
Aceste informa Ńii reprezint ă baza de plecare pentru luarea deciziilor, dar și o metoda de evaluare a
calita Ńii deciziilor luate. Obiectivele trebuie s ă fie stabilite clar și f ăcute cunoscute tuturor celor
implica Ńi în activitatea organiza Ńiei. Pentru ca un obiectiv s ă poat ă sta la baza unei decizii eficiente
trebuie s ă defineasc ă și o metod ă de m ăsurare pentru stabilirea în orice moment a abaterii înregistrate
în activitatea curent ă.

Proiectarea sistemelor informatice de gestiune
Stadiul actual și tendinșele dezvoltării sistemelor informatice E 36 Odat ă stabilite obiectivele clare, metodele de m ăsurare ale acestor obiective și metodele de evaluare,
se pune întrebarea: Cum poate o organiza Ńie să ob Ńin ă și s ă distribuie informa Ńiile necesare pentru
luarea deciziilor și evaluarea eficien Ńei acestora? R ăspunsul la aceast ă întrebare este: Prin solu Ńii de
Business Intelligence.

Putem defini Business Intelligence drept platform ă de prezentare a informa Ńiilor într-un mod corect,
util și specific c ătre fiecare persoan ă de decizie în timp util pentru a putea servi în lu are deciziilor
eficiente .

Business Intelligence nu reprezint ă un set de rapoarte tip ărite sau prezentate pe ecran. Rândurile unui
raport de vânz ări, spre exemplu, pot con Ńine informa Ńii detaliate și exacte, dar nu reprezint ă o solu Ńie
de Business Intelligence pân ă când nu sunt puse într-un format care poate fi u șor în Ńeles și interpretat
de c ătre o persoan ă de decizie în vederea stabilirii unei solu Ńii eficiente pentru o situa Ńie particular
întâlnit ă în activitatea curent ă.
3.3. Sistemul informatic de gestiune
Sistemul informatic de gestiune este sistemul informatic folosit pentru administrar ea ți controlul
resurselor unui sistem economic , deoarece termenul de gestiune are semnifica Ția, pe de o parte, de
„administrare a bunurilor unei întreprinderi“ Ți, pe de alt ă parte, de „r ăspundere a p ăstr ării bunurilor
Ți amânuirii fondurilor unei întreprinderi“ ale c ărei bunuri sunt reprezentate de resursele necesare
pentru realizarea obiectivelor sale, denumit ă generic sistem economic. [Andronie, 2007]

Administrarea Ți controlul resurselor unui sistem economic impun a dministrarea Ți controlul
activit ăȚilor pe care le desf ăȚoar ă sistemul economic respectiv pentru îndeplinirea ob iectivelor sale.

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 37 Capitolul 4
Metodologii de realizare
a sistemelor informatice
Procedeele pentru definirea, organizarea practic ă și etapizarea activit ăŃilor analizei de sistem constituie
așa numitele metodologii pentru analiza și proiectarea sistemelo r și reprezint ă obiectul
preocup ării unui num ăr mare de speciali ști din întreaga lume.

Metodele și conceptele fundamentale de realizare a sistemelor informatice pentru un organism
oarecare au la baz ă termenii de metod ă și metodologie asocia Ńi direct domeniului respectiv. Ace ști
termeni vor fi actualiza Ńi în raport cu specificul domeniului analizat, evol u Ńia cadrului legislativ,
dinamica activit ăŃii de informatic ă și tendin Ńele fundamentale de evolu Ńie a sistemului analizat. Pentru
realizarea sistemelor informatice se utilizeaz ă urm ătoarele concepte:
/lozenge6 Metoda : reprezint ă modul unitar sau maniera comun ă în care anali știi de sistem, programatorii și
alte categorii de persoane implicate, realizeaz ă procesul de analiz ă a sistemului informa Ńional –
decizional, proiectarea și introducerea sistemului informatic; sau reprezint ă totalitatea
conceptelor, modelelor, nivelelor, etapelor și tehnicilor specifice de formalizare necesare pent ru
defini Ńiile, listele, comunica Ńiile, datele și prelucr ările specifice unui sistem informatic.
/lozenge6 Metodologia : este reprezentat ă de setul finit particular definitoriu al unei meto de prin intermediul
unui sistem coerent de formulare și/sau procese informatice necesare pentru modelarea și
formalizarea total ă a unui sistem informatic.
/lozenge6 Tehnici de lucru : reprezint ă felul în care se ac Ńioneaz ă eficient și rapid, în cadrul unei metode,
pentru solu Ńionarea diferitelor probleme ce apar în procesul de proiectare.
/lozenge6 Instrumentele : utilizate în proiectarea sistemului informatic, s unt acele mijloace care se
utilizeaz ă de c ătre echip ă pentru realizarea scopului propus, ele depind de m etodele și tehnicile
utilizate, precum și de procedurile analizate și proiectate.
/lozenge6 Procedee de lucru (procedur ă): succesiunea opera Ńiilor necesare parcurgerii unor etape ale
ac Ńiunii și aplic ării unor tehnici în cadrul metodelor în conformitat e cu o rutin ă de lucru dat ă.
Este bine cunoscut faptul c ă preocup ările pentru analiza și proiectarea sistemelor informatice au ap ărut
ca rezultat al aplic ării unora dintre ideile analizei sistemice în tehni ca folosirii echipamentelor
moderne de culegere, prelucrare și stocare a informa Ńiei. De aici decurge faptul ca metodologiile de
analiz ă și proiectare a sistemelor informatice trebuie s ă fie axate în primul rând pe utilizarea eficient ă a
calculatoarelor electronice, pe valorificarea posib ilit ăŃilor și facilit ăŃilor pe care le ofer ă acestea
proiectan Ńilor de sisteme și în final utilizatorilor. Pe de alt ă parte, metodologiile de analiz ă și
proiectare a sistemelor informatice tind s ă integreze calculatorul în însu și procesul de analiz ă.
Sintetizând cele prezentate, se poate aprecia c ă:
/lozenge6 O prim ă caracteristic ă a metodologiilor de analiz ă și proiectare a sistemelor informatice este
orientarea spre solu Ńii care prev ăd organizarea centralizat ă a informa Ńiei în unit ăŃile care fac
obiectul analizei.
/lozenge6 O a doua caracteristic ă a metodologiilor de analiz ă și proiectare a sistemelor informatice deriv ă
din posibilit ăŃile remarcabile de prelucrare rapid ă a informa Ńiilor pe care le ofer ă calculatoarele.
Metodologiile de analiz ă și proiectare a sistemelor informatice sunt numeroas e iar alegerea uneia sau
alteia în cadrul proiect ării unui sistem informatic este o op Ńiune destul de grea și care, de obicei, Ńine
cont de preg ătirea specialistului în utilizarea și cunoa șterea cât mai multor metode.

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 38 În func Ńie de modul de abordare și domeniul de aplicabilitate, metodologiile utiliza te sunt:
[Lungu1&alt, 1995]
1. Din domeniul gestiunii : AXIAL, al firmei IBM; MERISE, Ministerul Industri ei din Fran Ńa; IE,
James Martin; DA, Universitatea Michigam; SSADM, Ma rea Britanie.
2. Orientate obiect , se bazeaz ă în formalizarea sistemelor pe no Ńiunea de obiect (entitate pentru
date și ac Ńiune pentru procese): OMT, General Electric SUA; OO D, SUA; ISD, Michael Jackson.
3. Pentru conducerea proiectelor de sisteme informatic e , se utilizeaz ă pentru elaborarea
sistemelor într-o concep Ńie știin Ńific ă: SDM/S; METHOD/1; NAVIGATOR (Ernest /Zoung –
James Martin).
O alt ă clasificare a metodologiilor de realizare a sistem elor informatice, care este cu prec ădere utilizat ă
în prezent este:
1. Metodologii cadru, cu scop orientativ general.
2. Metodologii proprii unor firme produc ătoare de echipamente de calcul sau sisteme informat ice.
Metodologiile de realizare a sistemelor informatice cuprind:
1. Modalitatea de abordare a sistemelor.
2. Regulile de formalizare a datelor și a proceselor de prelucrare.
3. Instrumente pentru concep Ńia, realizarea și elaborarea documenta Ńiei.
4. Modalitatea de derulare a proiectului și ac Ńiunile specifice fiec ărei etape (ciclul de via Ńă ).
5. Definirea modului de lucru.
6. Modalit ăŃi de administrare a proiectului.
Tendin Ńele actuale în evolu Ńia metodologiilor de proiectare sunt:
1. Înl ăturarea monopolul de Ńinut de-a lungul unei perioade de timp de anumite m etodologii, precum
MERISE în Fran Ńa și SSADM în Marea Britanie.
2. Îmbog ăŃirea reciproc ă a metodologiilor existente.
3. Asimilarea tendin Ńelor fire ști de evolu Ńie a informaticii (arhitectura client/server, abord area pe
obiecte, modelul rela Ńional pentru date).
4. Tendin Ńa spre standardizare:
• modelul entitate-rela Ńie pentru date;
• diagrama de flux pentru aspectele func Ńionale;
• modele de prelucrare și de comunica Ńie pentru aspectele „dinamice”.
5. Integrarea metodologiilor existente, a limbajelor d e modelare și a instrumentelor în cadrul unor
procese de dezvoltarea software care permit modelar ea mai flexibil ă a sistemului.
Pe parcursul timpului aceste metode, mijloace și tehnici specifice analizei de sistem au evoluat î n mod
considerabil, și ar fi imposibil ca s ă se poat ă surprinde toate aceste metode care au existat și care exist ă
în momentul de fa Ńă . Din acest motiv se vor enumera cele mai important e dintre metodologiile
existente, și se va insista pe una din metodologiile de dat ă recent ă, metodologia UML.
4.1. Etape în proiectarea unui sistem informatic
Realizarea unui sistem informatic implic ă mai multe etape teoretice. Acestea pot fi sistemat izate astfel:
/lozenge6 stabilirea cerin Ńelor utilizatorului;
/lozenge6 analiza și specificarea produsului;
/lozenge6 proiectarea general ă și de detaliu;
/lozenge6 implementarea codului;
/lozenge6 testarea produsului;
/lozenge6 instalarea și mentenan Ńa produsului.
În practic ă, majoritatea anali știlor de sistem au tendin Ńa de a parcurge doar anumite etape, dac ă nu
chiar una singur ă, și anume aceea de scriere de cod. În general acest l ucru este explicat prin lipsa de

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 39 timp și în cele mai multe cazuri, de incapacitatea benefi ciarului de a stabili și formula înc ă de la
început corect cerin Ńele produsului software.

Este îns ă adev ărat c ă nu orice produs software trebuie s ă parcurg ă toate etapele teoretice enumerate.
Dar tot atât de adev ărat este și faptul c ă, parcurgerea acestor etape, poate duce la rezultat e superioare și
la eliminarea unor erori de proiectare și programare înc ă din fazele ini Ńiale ale proiectului. Ceea ce este
mai d ăun ător este faptul c ă de obicei se renun Ńă la etapele de analiz ă și proiectare ale produsului, care
sunt etape cheie în dezvoltarea aplica Ńiei, ele furnizând o schematizare și o vedere de ansamblu, care
duc la o în Ńelegere mai profund ă a problemei abordate.

Proiectarea unei aplica Ńii software complexe, de dimensiuni mari, dezvoltat ă în cadrul unei echipe de
software, nu se face trecând direct la implementare a programului, ci trebuie s ă urmeze etapele
enumerate mai sus. Dup ă cum se observ ă, proiectarea nu se termin ă odat ă cu implementarea, pentru c ă
sistemul creat trebuie testat și apoi instalat. Dup ă instalarea produsului software acesta trebuie
între Ńinut, opera Ńie care trebuie realizat ă continuu.

Ceea ce s-a descris mai sus constituie unul din cel e trei cicluri ale metodologiilor utilizate în anal iza și
proiectarea sistemului, și anume ciclul de viaŃă al unui sistem informatic – o metodologie comun ă de
dezvoltare a sistemelor, caracterizat ă prin mai multe faze care marcheaz ă evolu Ńia eforturilor de
analiz ă și proiectare a sistemelor (Hoffer), și care constituie obiectul de studiu al ingineriei
program ării (este un domeniu care încearc ă o abordare sistematic ă a dezvolt ării, oper ării, între Ńinerii și
retragerii unui program de pe pia Ńă ).

În general în cadrul metodologiilor se pot distinge trei cicluri majore:
/lozenge6 Ciclul de via Ńă al unui sistem (recursivitate).
/lozenge6 Ciclul de abstractizare (sau ciclul de modelare, ra Ńionamentul).
/lozenge6 Ciclul de decizie (sau de validare, conducere).
Din punct de vedere al unei metodologii utilizate, sistemele informatice au un ciclu de via Ńă propriu,
care începe cu decizia de realizare a sistemului in formatic, cuprinde faza de elaborare, faza de utili zare
și faza de perfec Ńionare și se încheie cu decizia de abandonare a sa în forma existent ă și înlocuirea lui
cu un nou sistem.

Num ărul acestor etape variaz ă de la trei (analiz ă, proiectare, implementare) la peste dou ăzeci. Odat ă
cu apari Ńia abord ării orientate obiect etapele s-au diversificat. Tot odat ă, dup ă apari Ńia tehnicilor de
dezvoltare rapid ă a aplica Ńiilor (mediile RAD – Rapid Application Development ), num ărul etapelor s-a
redus din nou. Cu toate acestea, fiecare metod ă realizeaz ă dezvoltarea unui sistem într-o succesiune de
etape, sau faze, care difer ă de la un model la altul.

Ceea ce este important de re Ńinut este faptul c ă indiferent de ce subsistem se dore ște a fi implementat,
în realizarea acestuia se utilizeaz ă o anumit ă metod ă.

Cu toate acestea majoritatea modelelor prezint ă anumite etape tipice, care sunt:
1. Studiul și analiza sistemului existent . Aceast ă activitate include stabilirea caracteristicilor
generale, tehnico – economice, ale unit ăŃii analizate, cu prec ădere a func Ńiei de baz ă, precum și
studiul sistemului informa Ńional pentru conducere existent, ceea ce înseamn ă identificarea
caracteristicilor acestui sistem, a fluxului inform a Ńional și a metodelor și mijloacelor tehnice de
prelucrare a datelor.
2. Conceperea sistemului informatic , obiectul acestei etape îl constituie elaborarea p roiectului de
ansamblu al sistemului informatic, pe baza cerin Ńelor și restric Ńiilor formulate în prima etap ă.
3. Proiectarea de detaliu : obiectivul principal îl reprezint ă elaborarea componentelor func Ńionale
detaliate ale sistemului și a specifica Ńiilor de definire a produselor – program, în scopul accept ării
lor de c ătre beneficiar și întocmirii suportului documenta Ńiei de prezentare, utilizare și exploatare.

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 40 4. Elaborarea programelor . Aceast ă etap ă este consacrat ă elabor ării produselor – program și
procedurilor manuale aferente componentelor sistemu lui informatic, precum și test ării
componentelor.
5. Implementare sistemului , obiectivul principal al acestei etape este lansar ea în exploatare curent ă
a sistemului.
6. Exploatarea, întreŃinerea și dezvoltarea sistemului informatic .
Fiecare din aceste etape au la rândul lor mai multe activit ăŃi specifice. Astfel etapa de studiul și analiza
sistemului existent con Ńine urm ătoarele activit ăŃi:
/lozenge6 studiul sistemului existent;
/lozenge6 evaluarea sistemului existent;
/lozenge6 evaluarea gradului de preg ătire a unit ăŃii economice;
/lozenge6 formularea cerin Ńelor și a restric Ńiilor pentru realizarea sistemului informatic.
Conform raportului Euromethod etapele care trebuie parcurse în dezvoltarea sistemelor informatice
sunt:
/lozenge6 Planificarea strategică – cuprinde informa Ńii referitoare la organiza Ńia pentru care se elaboreaz ă
sistemul informatic, cât și la sistemul însu și.
/lozenge6 Studiul de fezabilitate – are rolul de a asigura informa Ńiile obiective necesare pentru a stabili
dac ă un proiect poate fi demarat sau nu. Dimensiunile și durata studiilor de fezabilitate variaz ă în
func Ńie de m ărimea și de natura sistemului de implementat.
/lozenge6 Definirea cerinŃelor – variaz ă în func Ńie de metoda utilizat ă. În general, func Ńiile acestei etape
sunt: în Ńelegerea scopului și func Ńiile sistemului, specificarea func Ńiilor din perspectiva
utilizatorului.
/lozenge6 Proiectarea – cuprinde la rândul s ău proiectarea logic ă și proiectarea tehnic ă.
/lozenge6 Codificarea – reprezint ă activitatea de transformare a algoritmilor defini Ńi în etapa de proiectare
într-un limbaj de programare.
/lozenge6 Implementarea – este etapa în care are loc procesul de instalare a echipamentelor și a sistemului
informatic (software-ului) în vederea finaliz ării sistemului și d ării lui în func Ńiune.
/lozenge6 ÎntreŃinerea și dezvoltarea – se refer ă la între Ńinerea sistemului elaborat.
4.2. Modele utilizate în proiectarea
unui sistem informatic
În prezent exist ă mai multe modele de realizare a sistemelor informa tice (numite modele ale ciclului
de via Ńă ale dezvolt ării sistemului), printre care pot fi men Ńionate:
/lozenge6 Modelul liniar (în cascad ă, sau Waterfall) este cel mai vechi și cel mai cunoscut model. A fost
dezvoltat în perioada anilor 1960 (a fost lansat la începutul anilor 1970 de c ătre W.W. Royce),
caracteristica principal ă constând în parcurgerea succesiv ă a unor etape, numite „ faze ”, fiecare
faz ă constituie o trecere de la un nivel de abstractiza re ridicat la un nivel mai sc ăzut de
abstractizare. Printre dezavantajele cele mai impor tante sunt urm ătoarele: dac ă s-a produs o
eroare este foarte greu de revenit la faza la care s-a produs eroarea; metoda a fost dezvoltat ă într-
o perioad ă când sistemele dominante erau cele de dimensiuni m ici și cu o arhitectur ă compact ă;
nu se preteaz ă la transpunerea s ă pe calculator. Fazele, la rândul lor, sunt structu rate pe activit ăŃi
și subactivit ăŃi. Trecerea la faza urm ătoare se realizeaz ă dup ă parcurgerea în întregime a fazei
precedente. Modelul este folosit de Booch în fazele de proiectare și implementare din cadrul
metodei OOADA ( ObjectîOriented Analysis and Design with Applicatio n ) și Ivar Jacobson
pentru toate etapele metodei OOSE ( ObjectîOriented Software Engineering ). Ideea de baz ă a
modelului este reg ăsit ă și în alte modele, cum ar fi: modelul V, modelul inc remental, și modelul
fântânei arteziene.

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 41 • Modelul incremental (rapid-prototyping) a fost creat pentru a acoperi deficien Ńele modelului
liniar; diferen Ńa principal ă între aceste modele const ă în introducerea conceptului de dezvoltare
incremental ă. Conceptul de dezvoltare incremental ă se refer ă la crearea unor mici salturi de la
vechea variant ă de sistem la noua variant ă care con Ńine un plus de func Ńii.
• Modelul de concepŃie în „V” : pentru eviden Ńierea faptului c ă anumite faze ale ciclului de via Ńă
sunt condi Ńionate de faze anterioare s-a propus reprezentarea ciclului de via Ńă al unui sistem
informatic ca un ciclu de concep Ńie în „V”. Acest tip de model a fost lansat în 1990 de Ould. Un
mare dezavantaj al acestei metode este acela c ă nu se poate valida analiza f ăcut ă la începutul
proiectului decât atunci când toate activit ăŃile de programare, testare și integrare sunt terminate.
• Modelul operaŃional realizeaz ă specifica Ńii “executabile”, m ăre ște rolul automatiz ării și
stabile ște o strâns ă leg ătur ă între specifica Ńii și implementare etc.
Atunci când se începe dezvoltarea unui sistem se po ate alege unul din modelele prezentate, sau altele
existente.

Problema cu cele mai multe metode este c ă ele au atât reguli implicite cât și explicite. Regulile
explicite sunt prezentate de obicei în documenta Ńia de realizare, iar cele implicite nu sunt prezent ate
nic ăieri.

Alegerea modelului depinde de m ărimea sistemelor de analizat și dezvoltat, precum și de domeniile
cărora le apar Ńin. O alt ă latur ă care trebuie avut ă în vedere atunci când se alege o metod ă sau alta este
modalitatea de abordare a sistemului: în întregime sau pe p ărŃi componente. Un alt aspect, dar nu
neap ărat ultimul, care trebuie abordat este “informa Ńizarea” metodei de proiectare. Informa Ńizarea
reprezint ă un suport pentru o metod ă și este o parte integrat ă în procesul de dezvoltare a sistemului
informatic.
4.3. Metodologii de analiză și proiectare
a sistemelor informatice
Metodologiile de analiz ă și proiectare a sistemelor informatice au ap ărut ca o necesitate de definire a
unor pa și și reguli generale, ce trebuie îndeplinite pentru an aliza, proiectarea și implementarea
diferitelor tipuri de probleme. Pentru a nu “descop eri” de fiecare dat ă procedeul care a dus la succesul
realiz ării unui produs anterior, s-a c ăutat definirea unor metode pragmatice de structurat e și ulterior de
analiz ă și proiectare a acestora. “Reutilizarea” este un cuv ânt cheie în dezvoltarea aplica Ńiilor din
ultimii ani, iar acesta nu se refer ă numai la reutilizarea p ărŃilor de cod, ci la toat ă experien Ńa acumulat ă
pe parcursul dezvolt ării produsului software.

Un factor important care a dus la apari Ńia conceptului de reutilizare, în special în ingine ria program ării,
este timpul , termenele realiz ării proiectelor devenind tot mai scurte. Astfel pro dusul este dezvoltat “din
mers”, în sensul c ă programatorul încearc ă s ă ghiceasc ă și s ă implementeze cerin Ńele schematice ale
clientului. Acesta urmeaz ă s ă formuleze cerin Ńele efective pornind de la prototipul furnizat de
programator.

Întrebarea fireasc ă este de ce nu exist ă o singur ă metodologie care s ă fie general valabil ă și aplicabil ă
în toate cazurile ? Un r ăspuns posibil este acela c ă metodologiile difer ă între ele destul de mult, fiind
mai eficiente în anumite domenii sau cazuri. Ele au luat na ștere din generalizarea solu Ńiilor oferite pe
cazuri particulare.
4.3.1. Metodologii de analiză sistemică
łinându-se cont de complexitatea celor mai multe sis teme existente în natur ă studierea sistemelor se
face într-o manier ă aparte numit ă abordare sistemic ă. Spre deosebire de abordarea cartezian ă, care

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 42 const ă în a separa și a izola fiecare subproblem ă pentru o prelucrare ulterioar ă, abordarea sistemic ă
propune o viziune unic ă și global ă a problemei de rezolvat.

O idee important ă care caracterizeaz ă analiza sistemic ă, și implicit a sistemelor informatice, este
posibilitatea perfec Ńion ării sistemelor printr-o activitate de analiz ă și proiectare știin Ńific ă a acestora. O
alt ă idee fundamental ă, specific ă analizei de sistem este caracterul s ău multidisciplinar. Organizarea
acestor activit ăŃi multidisciplinare constituie o alt ă idee de baz ă a analizei de sistem și poate cea mai
important ă dintre toate.

O problem ă decisiv ă este alegerea metodei ce urmeaz ă a fi aplicat ă pentru fiecare caz în parte. Se
poate afirma c ă, acesta este pasul cel mai important în desf ăș urarea proiectului. Dac ă alegerea f ăcut ă
este corect ă, acest fapt va duce la rezultate pozitive din toat e punctele de vedere. În cazul în care s-a
optat îns ă pentru o metod ă nepotrivit ă problemei de rezolvat, rezultatele proiectului vor fi pe m ăsur ă
(din aceast ă cauz ă sunt situa Ńii când la sfâr șitul proiectului se constat ă c ă aplica Ńia trebuie reproiectat ă
și implementat ă într-un mod diferit).

Alegerea aplic ării metodei pentru rezolvarea unei anumite probleme depinde de mai mul Ńi factori,
printre care amintim:
/lozenge6 tipul problemei de rezolvat;
/lozenge6 domeniul în care se încadreaz ă problema;
/lozenge6 preg ătirea și calificarea echipei de dezvoltare a produsului so ftware;
/lozenge6 resursele hardware și software disponibile;
/lozenge6 bugetul și timpul alocat proiectului.
În leg ătur ă cu evolu Ńia și progresele din ultimii ani în analiza de sistem, se poate descifra dou ă
principale tendin Ńe de aplicare ale acestei metodologii:
/lozenge6 un sens restrâns , în acest sens analiza se orienteaz ă în special spre aspecte legate de culegerea,
transmiterea, prelucrarea și stocarea informa Ńiilor într-un sistem f ără a se aprofunda procedeele
știin Ńifice de rezolvare a problemelor decizionale aferen te muncii de conducere din sistemul
supus analizei. În general aceast ă variant ă se nume ște analiza și proiectarea sistemelor
informa Ńionale , iar metodologiile sunt de tip informa Țional.
/lozenge6 un sens mai larg , în care se include, pe lâng ă preocup ările enumerate mai sus, și pe cele care
vizeaz ă metodele de optimizare a problemelor de decizie. A ceast ă variant ă este denumit ă analiza
și proiectarea sistemelor informa Ńional-decizionale ., iar metodologiile sunt de tip informa Țional-
decizional.
Metodologii de tip informaŃional
Printre tehnicile de analiz ă sistemic ă din a șa numit ă genera Ńia a II-a, o mare utilizare au cunoscut-o
grilele de analiz ă informa Ńional ă neautomatizat ă, a c ăror sarcin ă era de a stabili informa Ńiile de intrare
în sistem necesare pentru ob Ńinerea anumitor documente de ie șire.

Printre primele metode de analiz ă informa Ńional ă cu ajutorul grilei temporale automatizate, un
instrument metodologic auxiliar al analistului, car e au stabilit rela Ńia între intr ări și ie șiri a fost metoda
T.A.G. ( Time Automated Grid ) – grila automatizat ă de analiz ă) [Bodur&alt, 1982], propus ă mai întâi
în 1962 ca o tehnic ă manual ă și apoi pus ă la punct în anul 1966 de firma I.B.M., care realiz a
automatizarea unei p ărŃi a procesului de analiz ă, permi Ńând definirea unei baze de date minimale
pentru un anumit sistem, precum și definirea unor importante opera Ńii auxiliare pentru utilizarea
eficient ă a respectivei baze de date. T.A.G. este definit ă ca o tehnic ă general aplicabil ă pentru
proiectarea sistemelor informatice în domeniul come rcial; ea î și propune s ă asiste pe analist chiar din
faza releveului informa Ńional, cu o finalitate multipl ă: pentru colectarea și analiza datelor, pentru
sistematizarea acestora în colec Ńii sau fi șiere și apoi pentru definirea fluxurilor informa Ńionale prin
activit ăŃi.

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 43 Tehnica T.A.G. apeleaz ă la principiul regresiv: se porne ște de la ultimele ‘ie șiri’ ale sistemului supus
cercet ării (ie șiri pentru care analistul determin ă necesarul de informa Ńii și-l înscrie pe un formular
special); din acestea, T.A.G. determin ă necesarul de intr ări pentru faza în amonte a fluxului
informa Ńional, grupându-le dup ă momentul lor de apari Ńie și apoi, iterativ, solicit ă analistului date
ș.a.m.d. pân ă la primele “intr ări”, din afara sistemului. În acest mod T.A.G. poat e s ă defineasc ă o baz ă
de date minimal ă pentru sistemul respectiv, c ăutând totodat ă s ă reducă și durata total ă a fluxului
informa Ńional.

Aceste procedee de analiz ă cu ajutorul grilei automatizate fac parte din tend in Ńa de abordare a
problemelor nedecizionale dintr-un sistem, progresu l fa Ńă de metodele din genera Ńiile I și a II-a
constând doar în transferarea c ătre calculator a unora dintre opera Ńiile care erau efectuate manual.

Preocup ările de a integra calculatorul în procesul de anali z ă sistemic ă s-au soldat cu elaborarea unor
procedee care reu șesc s ă automatizeze par Ńial sau total unele din activit ăŃile de analiz ă. Ceea ce au în
comun toate aceste procedee este faptul c ă ale se axeaz ă în exclusivitate asupra analizei și proiect ării
sistemului informatic, asupra elabor ării automate a programelor și a corel ării lor într-un sistem.
Cerin Ńele sistemului se presupun a fi gata definite, ceea ce înseamn ă c ă analiza și proiectarea
informa Ńional – decizional ă r ămâne s ă fie executate manual.

Una dintre cele mai evoluate tehnici din aceast ă categorie (proiectarea sistemelor integrate) o
reprezint ă sistemul I.S.D.O.S. (Information System Design and Optimization System ), elaborat
de un grup de cercet ători de la Universitatea din Michigan, condu și de profesorul Daniel Teichroew.

Sistemul I.S.D.O.S. cuprinde mai multe metode care se înl ănŃuie pentru a prelua specifica Ńiile
cerin Ńelor, a le corela, a organiza etapele proiect ării sistemului informatic aferent, în scopul ob Ńinerii
cerin Ńelor cu ajutorul unor grafuri A.D.C. 1 și în final a elabora fi șierele sistemului.

Caracterizarea general ă a acestor procedee este faptul c ă ele sunt necomputerizate, ceea ce nu
înseamn ă c ă nu se orienteaz ă spre promovarea unor metode de analiz ă logic ă riguroas ă și spre
algoritmizarea opera Ńiilor componente. Ceea ce le diferen Ńiaz ă radical este faptul c ă nu utilizeaz ă
calculatorul în munca de analiz ă, ci momentul când este necesar ă folosirea lor în analiza de sistem.

Tot în jurul anilor 1960 o serie de mari firme cons tructoare de calculatoare elaboreaz ă metodologii
care încearc ă s ă etapizeze și s ă sistematizeze opera Ńiile necesare proiect ării unui sistem de conducere
bazat pe utilizarea calculatoarelor. Cea mai reprez entativ ă metod ă este S.O.P. ( Study OrganizaŃion
Plan ), elaborat ă de firma I.B.M.

Aceste metode sunt singurele care cuprind descriere a întregii munci de analiz ă și proiectare a
sistemelor, cu parcurgerea tuturor etapelor și fazelor, de la studii preliminare, pân ă la implementarea,
bineîn Ńeles la nivelul hardware – ului și software – ului de atunci și f ără a integra calculatorul în îns ăș i
munca de analiz ă.

Aceste metodologii elaborate, în general, de divizi unile de cercetare ale marilor firme de calculatoar e
reprezint ă o pozi Ńie intermediar ă, de trecere de la metodologiile cu specific de ana liz ă-proiectare a
sistemelor pur informatice spre metodologiile A.S.I .D. – metodologii de analiz ă și proiectare
informa Ńional–decizional ă.
Metodologii de tip informaŃionalEdecizională
Metodologiile de analiz ă și proiectare informa Ńional – decizional ă pun la dispozi Ńia analistului de
sisteme procedee cuprinz ătoare și eficiente în vederea perfec Ńion ării activit ăŃii social – economice.
Printre caracteristicile metodologiilor A.S.I.D. su nt diversitatea și mobilitatea lor; aceste metodologii

1 A.D.C. = analiza drumului critic, metod ă de conducere a ac Ńiunilor complexe

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 44 nu formeaz ă înc ă un ansamblu unitar, standardizat, de reguli și prescrip Ńii, ci constituie elaborate –
unicat, destul de deosebite unul de altul în ceea c e prive ște terminologia, cât și în ceea ce prive ște
împ ărŃirea în etape, subetape și faze și chiar în privin Ńa modului în care aplic ă ideea principal ă care st ă
la baza lor – regula priorit ăŃii aspectelor decizionale.

O alt ă caracteristic ă important ă a metodologiilor A.S.I.D. o constituie abordarea p roblemelor și
sectoarelor vitale ale societ ăŃii, acelea în care problematicile decizionale sunt mai complexe și în care,
prin optimizarea fluxurilor informa Ńional – decizionale, se pot ob Ńine avantaje considerabile.

Tot atât de însemnat ă este și o alt ă tr ăsătur ă fundamental ă a metodologiilor A.S.I.D., și anume
caracterul lor multidisciplinar (utilizarea unor me tode și tehnici apar Ńinând metodologiilor de analiz ă
de tip informatic, la care se adaug ă procedee preluate din cercetarea opera Ńional ă, dinamica industrial ă,
tehnici de simulare etc.).

Care ar fi diferen Ńa dintre metodologiile de analiz ă – proiectare a sistemelor informatice și cele de
analiz ă și proiectare a sistemelor informa Ńional – decizionale ? În realitate, un sistem infor matic va
apar Ńine întotdeauna unui sistem informa Ńional – decizional, analiza pur informatic ă și de programare
reprezentând o subetap ă a analizei sistemului informa Ńional – decizional.

Mai târziu s-au elaborat metodologii de analiz ă și proiectare informa Ńional – decizional ă de tip
ameliorativ, care se orienteaz ă în special spre rezolvarea problemelor decizionale din sistem și care
propun diverse procedee de integrare a metodelor ce rcet ării opera Ńionale pentru optimizarea deciziilor
din sistemul proiectat, precum și utilizarea psihosociologiei în îns ăș i munca de analiz ă. Metodologiile
ameliorative se caracterizeaz ă prin faptul c ă pleac ă de la sistemul informa Ńional – decizional real, în
func Ńiune, al unei societ ăŃi sau al unei p ărŃi din aceasta și î și propun îmbun ătăŃirea acestui sistem,
preluând tot ce este bun în el, dar în acela și timp transformând ceea ce poate fi perfec Ńionat.

Deci sintetizând se poate spune c ă metodologiile A.S.I.D. se pot grupa în dou ă mari categorii:
/lozenge6 metodologii care pornesc de la o exploatare prealab il ă cât mai am ănun Ńit ă a situa Ńiei prezente a
sistemului, procedând apoi, prin îmbun ătăŃiri succesive, la elaborarea unui nou proiect de si stem
adic ă metodologii ameliorative ;
/lozenge6 metodologii ce î și propun s ă construiasc ă un proiect de sistem, pornind de la descrierea (re leveul)
situa Ńiei de fapt, cât și de la o analiz ă fundamental ă a obiectivelor pe care este chemat s ă le
satisfac ă sectorul supus (re)proiect ării; acestea se cunosc sub numele de metodologii
constructive sau aval – amonte .
Dintre cea mai cunoscut ă metodă de analiză aval – amonte este cea a lui André Delville , care a
fost elaborat ă în Fran Ńa în anul 1966. La baza metodei aval – amonte st ă ideea conform c ăreia întreg
sistemul de elaborare, circula Ńie și prelucrare a informa Ńiei trebuie construit de la obiectivele
economice concrete ale societ ăŃii. Cunoscând obiectivele, printr-un procedeu deduc tiv se stabilesc
informa Ńiile “în aval” adic ă cele necesare realiz ării obiectivelor (informa Ńii care reprezint ă cerin Ńele
informa Ńionale ale sistemului). Apoi, tot deductiv, se dete rmin ă informa Ńiile “în amonte”, adic ă
necesare a fi prelucrate pentru ob Ńinerea informa Ńiilor în aval și totodat ă procesele de prelucrare,
inclusiv cele decizionale, prin care se transform ă informa Ńiile din amonte în informa Ńii – aval.
Procedeul se repet ă din aproape în aproape, urm ărind din spre aval spre amonte întreaga cascad ă
informa Ńional – decizional ă pân ă se ajunge la informa Ńiile care provin din afara sistemului și care
reprezint ă informa Ńiile de intrare.

În etapa urm ătoare se aleg mijloacele tehnice și metodele decizionale necesare și avantajoase pentru
realizarea întregii succesiuni de opera Ńii informa Ńional – decizionale stabilite prin parcurgerea casc adei
aval – amonte.

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 45 Așadar, metoda Delville se caracterizeaz ă prin analiza informa Ńional – decizional ă combinat ă, cu
ajutorul c ăreia se construie ște deductiv întregul sistem plecând de la necesit ăŃi informa Ńionale legate
de realizarea obiectivelor economice concrete, f ără a ignora sistemul informa Ńional existent din care se
poate prelua ceea ce este eficient. Metoda are în v edere utilizarea tehnicilor moderne de prelucrare
automat ă dar nu intr ă în detaliile proiect ării sistemului informatic.
4.3.2. Metodologii de analiză structurate
Aceste metodologii au ap ărut în principal din nevoia de a rezolva criza soft ware-ului (de a sistematiza
și organiza o aplica Ńie) ap ărut ă în anii 1970-1980. Analiza structurat ă a unei aplica Ńii se bazeaz ă pe
construirea unor diagrame de flux de date, aceasta fiind una dintre cele mai r ăspândite metodologii de
inginerie a program ării. Dificult ăŃile au ap ărut, îns ă, pentru etapa de analiz ă structurat ă a unei
probleme, etap ă care precede programarea; respectiv, a fost difici l de precizat cum trebuiau s ă arate și
ce trebuiau s ă con Ńin ă diagramele de flux de date.

În acest sens, au existat mai multe abord ări, dintre care se amintesc:
/lozenge6 Metodologia SADT (Structured Analysis and Design Technique ), reprezint ă o metodă grafic ă
utilizat ă pentru analiza cerin Ńelor și proiectare sistemelor. Forma s ă final ă a fost dezvoltat ă de
Douglas T. Ross în anul 1974, scopul principal fiin d în Ńelegerea și specificarea cerin Ńelor înaintea
începerii realiz ării efective a produsului software.
/lozenge6 Metodologia JSD (Jackson System Development ). JSD este o metodologie definit ă de Cameron
în 1989, reprezentând o extensie a metodei JSP ( Jackson Structured Programming ). Metoda
const ă în realizarea unei coresponden Ńe între structura problemei de rezolvat și structura unui
program. Aceast ă metod ă este recomandat ă a fi utilizat ă în cadrul aplica Ńiilor care se bazeaz ă pe
implement ări secven Ńiale și pe prelucrarea exclusiv ă a datelor de intrare (aplica Ńii financiare,
bancare și de asigur ări).
/lozenge6 Metodologia DSSD ( Data Structured System Development ), a fost introdus ă de Warnier în
1976. Ideea de baz ă pe care este construit ă metodologia este aceea c ă identificarea corect ă,
precis ă a structurilor de date ale problemei de rezolvat v a conduce la realizarea unui program
bine structurat și deci bine proiectat. Utilizarea acestei metode es te recomandat ă a fi utilizat ă
pentru aplica Ńii care au drept obiectiv principal procesarea date lor.
/lozenge6 Metodologia SA/SD ( Structured Analysis/Structured Design ) presupune folosirea unor
multitudini de diagrame pentru a descrie logic un s istem.
/lozenge6 Metodologia MERISE . Dezvoltarea metodei MERISE se datoreaz ă ini Ńiativei ministerului
francez al industriei, care a venit cu propunerea r ealiz ării unei metodologii de analiz ă și
proiectare a sistemelor informatice în timp real ce implic ă manipularea informa Ńiilor stocate în
baze de date. Scopul principal al acestei metode es te acela de concep Ńie a unui sistem
informa Ńional organiza Ńional și informa Ńizat.
/lozenge6 Metodologia Yourdon/Constantine , care mai este cunoscut ă și sub denumirea de proiectare
structurat ă, folose ște diagrama fluxului datelor pentru analiz ă, urmat ă de descompunerea
func Ńional ă specific ă urm ărind ob Ńinerea unor module stabile cu interconectare minim ă cu alte
module. Ca faze principale enumer ăm: studiul și analiza sistemului existent, conceperea
sistemului, proiectarea de detaliu, și elaborarea programelor.
/lozenge6 Metodologia Meyer , cunoscut ă și sub denumirea de proiectare compus ă, are drept obiectiv
minimizarea rela Ńiilor intermediare și maximizarea rela Ńiilor intramodulare. Aceast ă metod ă
permite o structurare a sistemului/programelor în f unc Ńie de fluxul datelor, specificându-se
ordinea de execu Ńie a unei func Ńii de prelucrare elementare sau agregate.
Metodologia MERISE
Dezvoltarea metodei MERISE se datoreaz ă ini Ńiativei ministerului francez al industriei, care a venit cu
propunerea realiz ării unei metodologii de analiz ă și proiectare a sistemelor informatice în timp real ce
implic ă manipularea informa Ńiilor stocate în baze de date.

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 46 Scopul principal al acestei metode este acela de co ncep Ńie a unui sistem informa Ńional organiza Ńional și
informatizat.

În prezent exist ă un produs informatic AMC*Designer, care implemente az ă metoda MERISE prin
formalizarea automat ă a unii sistem informatic și elaborarea unei documenta Ńii adecvate.

În cadrul metodei MERISE se face o distinc Ńie între aspectul static și dinamic al sistemului informatic,
pe de o parte, și viziunile de referin Ńă asupra acestui sistem (comunica Ńie; date, prelucr ări sau
tratamente; defini Ńii, descrieri, instrumente auxiliare). Astfel, aspectul static al unui sistem
informatic este reprezentat de comunica Ńii, defini Ńii și descrieri, deoarece, în principiu, aceste element e
sunt invariante în timp. Rezult ă c ă aspectul static are în vedere latura semantic ă a unui sistem
informatic. Aspectul dinamic este redat prin prelucr ări și date, elemente ce au un anumit grad de
variabilitate în raport strict cu evolu Ńia traiectoriei întregului sistem asociat unui orga nism.

Din punct de vedere al metodologiei MERISE, se dist ing trei cicluri care modeleaz ă și dezvolt ă noul
sistem informatic:
/lozenge6 ciclul de via Ńă (recursivitatea);
/lozenge6 ciclul de decizie (conducerea sau ciclul de validar e);
/lozenge6 ciclul de abstractizare (ra Ńionamentul sau ciclul de modelare).
Dac ă se utilizeaz ă reprezentarea tridimensional ă a acestor cicluri se ob Ńine urm ătoarea abordare:

Fig. 4.1. – Definirea etapelor de realizare a unui sistem in formatic
prin intermediul metodei MERISE
Aceste cicluri asigur ă folosirea urm ătoarelor elemente în realizarea unui sistem informa tic:
/lozenge6 Perioada de realizare , care este intervalul de timp în limitele c ăruia sunt realizate aspecte ale
unui astfel de sistem, adic ă sunt construite și / sau utilizate componentele globale ale unui ast fel
de sistem. În realizarea efectiv ă a unui sistem informatic exist ă trei perioade fundamentale:
• Perioada de concepŃie asigur ă definirea solu Ńiilor generale în termeni generali, evaluarea
solu Ńiilor de organizare și a celor tehnice, definirea complet ă a viitorului sistem informa Ńional
organiza Ńional. Perioada de concep Ńie are sarcina de a realiza punctul de vedere al
utilizatorului.
• Perioada de realizare va asigura specifica Ńiile tehnice complete ale viitorului sistem
informa Ńional informatizat, elaborarea procedurilor automat e necesare, inclusiv punerea în model la nivel concep Ńional
Abstrac Ńie model la nivel organiza Ńional
model la nivel fizic
concep Ńia sistemului informatic
Via Ńă realizarea sistemului informatic
men Ńinerea sistemului informatic
decizii globale
Decizie decizii organiza Ńionale
decizii tehnice
decizii func Ńionale

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 47 func Ńiune a noului sistem. Rezult ă c ă aceast ă perioad ă realizeaz ă punctul de vedere al
realizatorului noului sistem.
• Perioada de menŃinere în funcŃiune trebuie s ă asigure func Ńionarea efectiv ă, eliminarea
anomaliilor ap ărute și, eventual evolu Ńia sistemului realizat.
/lozenge6 Etapele (subetapele) sunt p ărŃi componente ale perioadei de concep Ńie, realizarea și men Ńinerea
în func Ńiune, prin intermediul c ărora se realizeaz ă anumite aspecte generale sau particulare ale
proiect ării noului sistem informatic. Aceste etape vor asig ura:
• vederea global ă asupra sistemului informa Ńional organiza Ńional;
• vederea extern ă, a utilizatorului sistemului informa Ńional organiza Ńional;
• vederea intern ă, a realizatorului sistemului informa Ńional informatizat;
• vederea func Ńional ă, a organismului respectiv.
Din cele prezentate rezult ă c ă pentru fiecare perioad ă de realizare exist ă etape specifice, prin
intermediul c ărora se realizeaz ă vederile aferente noului sistem, astfel:
Perioada Etapa Vederea asigurat ă
De concepere /square4 schema directoare
/square4 studiu de evaluare
/square4 studiu de detaliu
/square4 studiu organiza Ńional /square4 vedere directoare/global ă
/square4 vedere extern ă
/square4 vedere extern ă
/square4 vedere extern ă
De realizare /square4 studiu tehnic
/square4 proiectarea procedurilor
/square4 implementarea /square4 vedere intern ă
/square4 vedere intern ă
/square4 vedere intern ă
De men Ńiune în
func Ńiune /square4 exploatarea curent ă
/square4 între Ńinerea
/square4 dezvoltarea se noi versiuni /square4 vedere func Ńional ă
/square4 vedere func Ńional ă
/square4 vedere func Ńional ă
/lozenge6 Fazele utilizate în realizarea unui sistem informat ic sunt elementele componente ale unei
etape, prin intermediul c ărora sunt realizate aspecte pur particulare ale unu i segment unitar din
structura sistemului informatic abordat.
În mod concret, proiectantul sistemului informatic deruleaz ă aceste trei stadii pe tot parcursul
existen Ńei noului sistem. Aceste cicluri se desf ăș oar ă simultan prin intermediul etapelor de proiectare.

De asemenea trebuie amintit c ă aceast ă metod ă utilizeaz ă șase nivele de abstractizare:
/lozenge6 Nivelul global (NG) – are rolul de a coordona toate celelalte niv ele: conceptual, organiza Ńional,
logic, fizic și exploatare.
/lozenge6 Nivelul conceptual (NC) – acest nivel cuprinde componentele fundament ale pe care se va baza
noul sistem informatic, independent de restric Ńiile de organizare a organismului supus analizei
sau de dotarea prezent ă sau viitoare cu tehnic ă de calcul și de comunica Ńie.
/lozenge6 Nivelul organizaŃional (NO) – rezult ă din conversia nivelului conceptual, asigurând orga nizarea
comunica Ńiilor, datelor și prelucr ărilor în raport cu cerin Ńele compartimentale și umane.
/lozenge6 Nivelul logic (NL) – rezultă din conversia nivelului organiza Ńional, realizând detalierea acestuia
prin partajarea activit ăŃilor între utilizatorii din compartimentele organis mului și resursele
practice de tehnic ă de calcul utilizate concret. Practic acest nivel p oate conduce la mai multe
variante de organizare a noului sistem informatic.
/lozenge6 Nivelul fizic sau operaŃional (NF) – cuprinde stabilirea solu Ńiilor tehnice pentru asigurarea
comunica Ńiei, a datelor și a prelucr ărilor pentru noul sistem informatic proiectat.
/lozenge6 Nivelul de utilizare sau exploatare (NE) – acest nivel are ca surs ă nivelul fizic și se
concretizeaz ă practic prin modelul de func Ńionare efectiv ă a noului sistem informatic proiectat.
Nivelele conceptual și organiza Ńional sunt adaptate concep Ńiei sistemului informa Ńional, în timp ce
urm ătoarele trei nivele sunt asociate proiect ării sistemului informa Ńional informatizat.

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 48 Metoda MERISE folose ște concepte specifice pentru fiecare nivel și proces de modelare deoarece
aceasta trebuie s ă asigure urm ătoarele deziderate fundamentale:
1. În plan vertical , metoda MERISE permite urm ătoarele opera Ńii: abstractizarea, asigurarea solu Ńiei
de organizare, alegerea solu Ńiei tehnice, realizarea st ării de exploatare. Aceste opera Ńii sunt
realizate succesiv, pornind de la nivelul conceptua l, continuând cu cel organiza Ńional și terminând
cu cel de exploatare.
2. În plan orizontal , MERISE asigur ă trei nivele: nivelul de transmitere asigur ă trecerea de la
prelucr ările locale c ătre cele distribuite, nivelul de detaliu cuprinde t ransformarea de la general la
particular, nivelul de descriere asigur ă conversia între nivelele conceptual , organiza Ńional, logic,
fizic și exploatare
Conversia dintre planurile vertical și orizontal se asigur ă prin valid ări și interac Ńiuni între diferite
metode, aflate îns ă la acela și nivel de abordare.

Concluzionând se poate spune c ă proiectarea sistemelor informatice conform metodei MERISE
trebuie s ă se bazeze pe cele trei cicluri. Ea presupune parcu rgerea unor etape: elaborarea schemei
directoare; studiul prealabil; studiul detaliat; st udiul tehnic; elaborarea programelor; implementarea ;
men Ńinerea în func Ńiune a sistemului informatic.

Etapele de elaborare a schemei directoare, studiul prealabil și studiul detaliat reprezint ă de fapt
conceperea sistemului informatic. Studiul tehnic po ate s ă fac ă parte din conceperea sistemului
informatic sau din realizarea și lansarea lui în execu Ńie. Realizarea și lansarea în execu Ńie a sistemului
informatic este alc ătuit ă din etapele: elaborarea programelor și implementarea sistemului.

Fig. 4.2. – Corela Ńia ciclurilor metodei MERISE
Metodologia MERISE utilizeaz ă modelul entitate – rela Ńie pentru analiza și proiectarea modelelor
statice, și re Ńele Petri pentru modelele dinamice. decizi decizii de decizii
gl obale organizare tehnice Ciclul de decizie
G nivel global

C nivel conceptual

O nivel organiza Ńional

L nivel logic

F nivel fizic

E nivel exploatare
Ciclul de
abstractizare Studiul de evaluare SE per ioada

Proiectarea conceptual ă PC de

Proiectarea organiza Ńional ă PO concep Ńie

Proiectarea logic ă PL perioada

Proiectarea fizic ă PF de

Implementarea IMP realizare

Exploatarea curent ă EXC perioada

Între Ńinerea INT d e

Dezvoltarea de noi versiun i DNV men Ńinere
Ciclul de
via Ńă
Schema directoare

Proiectarea sistemelor informatice de gestiune
Metodologii de realizare a sistemelor informatice E 49 MERISE nu utilizeaz ă diagramele de flux de date care fac leg ătura între modelul static și cel dinamic.
De aceea, pentru a analiz ă și o proiectare complet ă și eficient ă a sistemelor informatice, se recomand ă
utilizarea acestei metodologii în conjunc Ńie cu alte tehnologii. Elementele care stau la baza opera Ńiei de
descriere a unui proces dinamic sunt urm ătoarele elemente: evenimente, opera Ńii și sincroniz ări. O
schem ă general ă de construire a unui model MERISE cuprinde urm ătorii pa și: construirea diagramei
de flux de date utilizând o alt ă tehnologie; ordonarea informa Ńiilor identificate și selectate; construirea
unui model liniar MERISE; verificarea sincroniz ării diferitelor opera Ńii.

Rezultatele utiliz ării MERISE constau în crearea unei vederi de ansamb lu asupra fluxului
informa Ńiilor, a ordinii temporale și a interdependen Ńelor dintre acestea. Aceste informa Ńii vor fi utile
atât la analiza, cât și la proiectarea sistemului.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 50 Capitolul 5 – Analiza și proiectarea
orientată obiecte
5.1. Concepte utilizate în tehnologia orientată obi ect
Proiectarea și analiza orientate obiect se bazeaz ă pe a șa numitul model obiectual . Acesta a introdus
principii precum abstractizarea, încapsularea datel or, modularizarea, ierarhia și persisten Ńa. Nici unul
din aceste principii nu este nou, dar ceea ce este important este faptul c ă toate aceste concepte sunt
tratate împreun ă, încercând armonizarea lor prin diferite tehnici.

Tehnologia orientat ă obiect reprezint ă esen Ńa combina Ńiei a patru idei: [Meyer, 1997]
/lozenge6 O metodă structurală care se aplic ă pentru descompunerea și reutilizarea software–ului.
Sistemele software permit anumite ac Ńiuni pe anumite tipuri ale obiectelor; pentru a ob Ńine un
sistem flexibil și reutilizabil, este indicat ca structura acestuia s ă se bazeze pe tipuri de obiecte și
nu pe ac Ńiuni. Conceptul care rezult ă este un mecanism mult mai puternic și multilateral numit
clasă , care în construirea software–ului orientat obiect serve ște ca baz ă atât pentru structura
modular ă cât și pentru tipul sistemului.
/lozenge6 O disciplină riguroasă este o abordare corect ă a problemei construirii software–ului pe care
aceasta trebuie s ă o suporte. Ideea este c ă orice sistem trebuie s ă fie tratat ca o colec Ńie de
componente care colaboreaz ă la îndeplinirea cu succes a sarcinilor.
/lozenge6 Principiul epistemologic se refer ă la întrebarea cum pot fi descrise clasele. În tehn ologia orientat ă
obiect, obiectele descrise printr-o clas ă sunt definite numai de modul în care ele pot fi ut ilizate:
opera Ńiile (cunoscute și sub denumirea de caracteristici ) și propriet ăŃile formale ale acestor
opera Ńii. Aceast ă idee este exprimat ă formal de teoria tipurilor de date abstracte .
/lozenge6 Tehnica de clasificare se ocup ă de observa Ńiile în urma c ărora munca este împ ărŃit ă pe domenii.
Software–ul nu face excep Ńie, și metoda orientat ă obiect se bazeaz ă pe o clasificare cunoscut ă sub
numele de moștenire .
Nu exist ă îndoieli asupra faptului c ă proiectarea orientat ă obiect este fundamental diferit ă fa Ńă de
metodele ap ărute anterior. Ea necesit ă un mod diferit de percep Ńie a problemelor, de în Ńelegere a
modului cum urmeaz ă s ă fie analizate, proiectate și implementate acestea. În centrul aten Ńiei se afl ă
no Ńiunea de obiect (respectiv de clas ă), aceasta punându- și amprenta asupra întregului proces de
proiectare și implementare.

O abordare orientată obiect se axeaz ă mai întâi pe identificarea obiectelor din domeniul supus
analizei, și apoi se alege procedura potrivit ă. Putem spune, la o prim ă vedere, c ă termenul de orientat
obiect înseamn ă organizarea software-ului ca o colec Ńie de obiecte discrete, fiecare obiect încorporând
atât structuri de date, cât și comportament.

Construc Ńia fundamental ă în abordarea orientat ă obiect o constituie obiectul care combin ă structura
datelor și comportamentul într-o singur ă entitate. Deci, un model orientat obiect va fi for mat dintr-un
număr de obiecte care constituie p ărŃi bine delimitate ale sistemului modelat. [V ătui, 2000]

Obiectul este o entitate care se poate distinge dintre alte entit ăŃi și care are o semnifica Ńie în contextul
aplica Ńiei modelate. Tot prin obiect se în Ńelege ceva asupra c ăruia se poate întreprinde o ac Ńiune sau
care poate întreprinde o ac Ńiune asupra altui obiect.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 51 Un obiect poate fi considerat o entitate care încorporeaz ă atât structuri de date (denumite atribute ),
cât și comportament (numite operaŃii ).

Pentru a fi un obiect, entitatea respectiv ă trebuie s ă aib ă urm ătoarele caracteristici:
/lozenge6 Identitatea : obiectul este o entitate discret ă, care se distinge dintre alte entit ăŃi.
/lozenge6 Clasificarea : obiectele cu acelea și atribute și opera Ńii se grupeaz ă în clase . Fiecare obiect poate
fi considerat drept o instanŃă a unei clase.
/lozenge6 Polimorfismul : aceea și opera Ńie (cu acela și nume) poate s ă aib ă comportament diferit în clase
diferite. Implementarea concret ă a unei opera Ńii într-o anumit ă clas ă se nume ște metodă .
/lozenge6 Moștenirea : atributele și opera Ńiile se transmit de-a lungul claselor bazate pe o r ela Ńie ierarhic ă.
Fiecare obiect este unic și se caracterizeaz ă prin:
/lozenge6 Identitate : înseamn ă c ă obiectele se disting între ele prin existen Ńă și nu prin atributele lor. G.
Booch define ște identitatea ca fiind “acea proprietate a unui ob iect care-l distinge de alte obiecte
”. Jim Rumbaugh define ște identitatea astfel:“o caracteristic ă distinctiv ă a unui obiect care indic ă
existen Ńa separat ă a obiectului chiar dac ă obiectul respectiv are aceea și valoare ca un alt obiect”.
/lozenge6 Stare : cuprinde toate atributele (de regul ă, statice) ale unui obiect împreun ă cu valorile curente
(de regul ă, dinamice) ale acestor atribute. Atributul poate f i o valoare simpl ă sau un alt obiect, iar
starea unui obiect influen Ńează comportamentul s ău la primirea unui nou mesaj. G. Booch
define ște starea unui obiect “… un set de valori p ăstrate în mod curent de atributele sale„.
/lozenge6 Comportament : reprezint ă activitatea s ă testabil ă și vizibil ă din exterior, el arat ă modul cum “un
obiect ac Ńioneaz ă și reac Ńioneaz ă, în termenii schimb ării st ării și comunic ării prin mesaje„ – G.
Booch.
Construirea modelului obiectelor este etapa cea mai important ă a metodologiei utilizate și reprezint ă
punerea în eviden Ńă atât a obiectelor, cu atributele și opera Ńiile proprii, cât și a rela Ńiilor dintre ele.
Modelul obiectelor reprezintă modelul static al une i aplicaŃii .

Un model este o no Ńiune abstract ă și este construit pentru a în Ńelege problema înainte de a implementa
solu Ńia. Cadrul conceptual, pentru abordarea orientat ă obiect, îl constituie modelul obiectului care
cuprinde urm ătoarele principii:
/lozenge6 Abstractizarea const ă în surprinderea aspectelor esen Ńiale ale unei entit ăŃi, între anumite
entit ăŃi, situa Ńii sau procese din lumea real ă și concentrarea numai asupra acestor similarit ăŃi
ignorând diferen Ńele dintre ele. De asemenea, abstractizarea presupu ne omiterea p ărŃilor
sistemului care nu sunt necesare pentru în Ńelegerea sistemului la un anumit nivel de detaliu.
Accentul, pentru un obiect, se pune pe ce este acesta și pe ce trebuie să facă , înainte de a
stabili concret detaliile de implementare. Acesta e ste motivul pentru care, în crearea unei aplica Ńii
orientate obiect, etapa esen Ńial ă este cea de analiz ă și nu de implementare.
/lozenge6 Încapsularea (ascunderea informa Ńiilor) este un principiu al abord ării orientate obiect care
prevede ca obiectele s ă constituie entit ăŃi de sine st ătătoare; atributele unui obiect nu sunt
accesibile utilizatorului în mod direct, ci doar pr in intermediul metodelor definite, care astfel
trebuie s ă se constituie într-un set cât mai complet de opera Ńii relative la obiect. Încapsularea este
un principiu derivat al abstractiz ării și const ă în separarea aspectelor externe ale unui obiect, c are
sunt accesibile altor obiecte, de aspectele impleme nt ării interne ale obiectului, care sunt ascunse
celorlalte obiecte, ceea ce face posibil ă modificarea implement ării obiectului f ără a afecta
aplica Ńiile care-l utilizeaz ă. Ea este legat ă de securitatea program ării, furnizând un mecanism care
asigur ă accesul controlat la starea și func Ńionalitatea obiectelor. Potrivit acestui mecanism, o clas ă
trebuie s ă aib ă membrii împ ărŃiŃi în dou ă sec Ńiuni: partea publică , care este constituit ă din
atributele și metodele pe care obiectele le ofer ă spre utilizare altor obiecte (reprezint ă partea de
interfa Ńă a obiectului respectiv), și partea privată , care cuprinde atributele și/sau metodele care
servesc exclusiv obiectelor clasei respective (r ămân inaccesibile utilizatorului).

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 52 /lozenge6 Modularizarea reprezint ă împ ărŃirea sistemului în obiecte individuale cu leg ături minime între
ele. Acest principiu ajut ă în munca de programare, deoarece duce la reducerea complexit ăŃii unui
program, prin împ ărŃirea acestuia în module mai mici, u șor de modificat și de implementat.
/lozenge6 Ierarhizarea reprezint ă ordonarea pe diferite niveluri a abstrac Ńiilor. Dup ă Grady Booch, cele
mai importante tipuri de ierarhii ale unui sistem c omplex sunt:
/circle4 ierarhia isEa, adic ă apartenen Ńa unei clase la o familie de clase de nivel mai îna lt, ceea ce se
traduce prin conceptul de mo ștenire;
/circle4 ierarhia isEpartEof , adic ă apartenen Ńa unei clase la o alt ă clas ă, în calitate de component ă,
ceea ce duce la apari Ńia rela Ńiei de tip parte-întreg (whole-part).
Împachetarea datelor și a comportamentului în acela și obiect , se refer ă la faptul c ă un obiect
con Ńine atât structuri de date, cât și de opera Ńii, și este util ă în cazul în care exist ă mai multe opera Ńii cu
acela și nume în clase diferite (în acest fel se va ști întotdeauna c ărei clase îi apar Ńine o anumit ă
metod ă). Existen Ńa unor opera Ńii (metode) diferite cu acela și nume, dar cu comportament diferit, se
nume ște polimorfism .

Partajarea . Acest concept este utilizat la diverse nivele. As tfel ea poate însemna transmiterea
acelora și structuri de date și opera Ńii de-a lungul unor clase dintr-o ierarhie de clase . Dac ă o clas ă
mo ștene ște o alt ă clas ă, atunci ea mo ștene ște toate atributele și opera Ńiile clasei de baz ă, iar din punct
de vedere al codului, acestea sunt identice cu cele ale clasei de baz ă, și nu copii ale lor.

O clasă de obiecte descrie o mul Ńime de obiecte cu atribute similare, comportament s imilar (opera Ńii)
și rela Ńii similare cu alte obiecte din sistem. Denumirea d e clasă de obiecte se poate utiliza similar cu
denumirea de clasă , iar în loc de obiect care aparŃine unei clase se poate utiliza no Ńiunea de instanŃă
a unei clase , fiecare obiect fiind o instan Ńă a unei clase. Obiectele din aceea și clas ă au o serie de
atribute comune și un comportament comun.

Dup ă cum se observ ă din figura 5.1., o clas ă poate fi:
/lozenge6 Clasă abstractă , este acea clas ă care nu are instan Ńe directe, dar ai c ărei descenden Ńi (subclase)
au instan Ńe directe.
/lozenge6 Clasă concretă este o clas ă cu instan Ńe directe. O clas ă concret ă poate avea subclase
(descenden Ńi) abstracte, dar care, la rândul lor, trebuie s ă aib ă descenden Ńi concre Ńi.
Pentru u șurarea descrierii se utilizeaz ă diferite diagrame de reprezentare a claselor și obiectelor.
Fiecare autor al unei metode de analiz ă și proiectare î și creeaz ă propriile nota Ńii pentru diagramele
folosite. Deosebirile între diferite abord ări se refer ă mai mult la nota Ńii decât la no Ńiunile utilizate,
conceptele de baz ă fiind în mare parte acelea și.

Fig. 5.1. – Model de definire a claselor într-o metod ă orientat ă obiect
La fel ca și obiectele, clasele au o viziune intern ă și una extern ă. Viziunea extern ă a unei clase este
dat ă de interfaŃa sa, care este format ă din declara Ńii privind toate opera Ńiile aplicabile clasei, dar
poate include și declara Ńii ale altor clase constante etc. Interfa Ńa poate fi:

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 53 /lozenge6 Publică , ceea ce înseamn ă c ă ea este accesibil ă tuturor clien Ńilor s ăi.
/lozenge6 Protejată , în acest caz clasa este accesibil ă numai clasei îns ăș i, subclaselor sale și claselor
prietene.
/lozenge6 Privată , clasa este accesibil ă numai clasei îns ăș i și claselor prietene.
Starea unui obiect trebuie s ă aib ă o anumit ă reprezentare în clasa din care face parte. Acest l ucru se
realizeaz ă sub form ă de declara Ńii de constante și variabile plasate în zona protejat ă sau privat ă a
interfe Ńei clasei. În acest mod, reprezentarea comun ă a tuturor instan Ńelor unei clase este încapsulat ă și
modificarea reprezent ării nu va afecta func Ńionalitatea nici unui obiect.

Implementarea clasei reprezint ă viziunea s ă intern ă care este format ă din toate opera Ńiile definite în
interfa Ńa clasei.

Un atribut reprezint ă o caracteristic ă a unei clase care are asociat un identificator și un tip. Valoarea
pe care o poate lua un atribut trebuie s ă fie compatibil ă cu tipul s ău. Un atribut care poate fi calculat
din alte atribute se nume ște atribut derivat .

Constrângerile sunt leg ături func Ńionale între entit ăŃile (obiect, clas ă, atribut, leg ătur ă sau asociere)
din cadrul unui model al obiectelor. O constrângere restric Ńioneaz ă valorile pe care le poate lua
entitatea.

O constrângere asupra unei leg ături poate fi ilustrat ă prin exemplu din figura 5.2.:

Fig. 5.2. – Constrângeri asupra unei leg ături și a unui atribut
O clas ă poate s ă con Ńin ă și constrângeri asupra atributelor (figura 5.2., data_fact>01.01.2004 ).
Acestea se numesc restricŃii . Ele se pot aplica și asupra unei subclase. De exemplu, un p ătrat este un
paralelipiped c ăruia i se pune condi Ńia ca toate laturile s ă fie egale; un cerc este o elips ă cu condi Ńia ca
ambele semiaxe s ă fie egale.

O operaŃie care face parte dintr-o clas ă este o func Ńie care se aplic ă obiectelor apar Ńinând clasei
respective. Fiecare opera Ńie are ca argument implicit clasa din care face par te. Opera Ńia poate fi
polimorfică , adic ă aceea și opera Ńie poate apare în mai multe clase diferite. O clas ă abstract ă poate s ă-
și defineasc ă ni ște opera Ńii, dar f ără s ă le implementeze. Aceste opera Ńii se vor numi operaŃii
abstracte . O subclas ă poate s ă redefinesc ă și o opera Ńie a unei superclase, aceasta numindu-se
redefinire ( overriding ).

OperaŃia unui obiect este o ac Ńiune pe care un obiect o execut ă asupra altui obiect pentru a primi o
reac Ńie din partea acestuia. Un mesaj este o opera Ńie pe care un obiect o execut ă asupra altui obiect. O
opera Ńie reprezint ă un serviciu pe care o clas ă îl ofer ă clien Ńilor s ăi. Cele cinci tipuri de opera Ńii pe care
un client le poate executa asupra unui obiect sunt:
Constrângeri asupra unei
leg ături Constrângeri asupra unui
atribut

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 54 /lozenge6 Modificare – în urma opera Ńiei starea unui obiect se modific ă.
/lozenge6 Selectare – opera Ńia acceseaz ă starea unui obiect f ără a o modifica.
/lozenge6 Iterare – opera Ńia acceseaz ă toate p ărŃile unui obiect într-o ordine bine definit ă.
/lozenge6 Constructor – opera Ńia prin care se creeaz ă un obiect și/sau se ini Ńializeaz ă starea sa.
/lozenge6 Destructor – opera Ńia prin care se distruge obiectul și/sau se elibereaz ă starea sa.
Metoda reprezint ă implementarea concret ă a unei opera Ńii pentru o anumit ă clas ă. Num ărul și tipul
argumentelor, împreun ă cu tipul valorii returnate, se nume ște semn ătura unei opera Ńii.

Obiectele contribuie la comportamentul sistemului c olaborând cu alte obiecte. Pentru a stabili rela Ńiile
și asocierile între obiecte se utilizeaz ă leg ături și asocieri. O legătură este o conexiune fizic ă sau
conceptual ă între obiecte. Din punct de vedere matematic, o le g ătur ă este un tuplu, adic ă o list ă
ordonat ă de instan Ńe de obiecte. Ca participant la o leg ătur ă, un obiect poate juca unul din urm ătoarele
roluri:
/lozenge6 Actor este un obiect care ac Ńioneaz ă asupra altor obiecte, dar asupra c ăruia nu poate ac Ńiona alt
obiect.
/lozenge6 Server este un obiect pe care pot opera alte obiecte, dar el nu poate opera niciodat ă asupra altor
obiecte.
/lozenge6 Agent este un obiect care opereaz ă asupra altor obiecte și asupra c ăruia pot opera alte obiecte. Un
agent lucreaz ă în numele unui actor sau unui alt agent.
Pe de alt ă parte, o leg ătur ă este o instan Ńă a unei asocieri. O asociere descrie un grup de leg ături cu
aceea și structur ă și aceea și semantic ă și sunt cele mai frecvente rela Ńii existente între clase.

Leg ăturile sunt de mai multe tipuri:
/lozenge6 Unu la unu (one-to-one), caz în care unei clase îi corespunde numai o singur ă clas ă.

Fig. 5.3. – Diagrama claselor (leg ătur ă unu la unu)
/lozenge6 Unu la mulŃi (one-to-many), în aceast ă situa Ńie unei clase îi pot corespunde mai multe clase.

Fig. 5.4. – Diagrama claselor într-o leg ătur ă unu la mul Ńi
/lozenge6 MulŃi la mulŃi (many-to-many), este cazul în care fiec ărei clase care particip ă într-o astfel de
leg ătur ă îi vor corespunde mai multe clase.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 55

Fig. 5.5. – Diagrama claselor într-o leg ătur ă mul Ńi la mul Ńi
Din punct de vedere al num ărului de clase care particip ă la o asociere aceasta poate fi: binară , ternară
și nEară .

Asocierile sunt caracterizate prin multiplicitate și prin ordonarea obiectelor (op Ńional) unei clase care
particip ă la asociere. Termenul de multiplicitate arat ă câte instan Ńe ale unei clase pot fi legate de o
singur ă instan Ńă a unei alte clase. Multiplicitatea este descris ă prin num ărul de instan Ńe care intervin în
leg ătur ă, trecut ă în dreptul liniei la unul sau la ambele capete ale ei (0, 1, 0..*, 1..*, 0..1, *).

De multe ori este necesar, ca în cadrul unei asocie ri mul Ńi s ă se specifice dac ă ordonarea este
important ă. În acest caz se va utiliza simbolul {ordered} în dreptul asocierii. Ordonarea este un caz
particular de constrângere asupra asocierii (capito lele unei c ărŃi sunt ordonate în cuprinsul acesteia).

Asocierile, la fel ca obiectele, pot avea un nume și atribute.

Uneori este necesar ca rela Ńia de asociere s ă fie modelat ă ca o clas ă, fiec ărei leg ături corespunzându-i
o instan Ńă a clasei respective. Ceea ce este important de re Ńinut este faptul c ă aceast ă nou ă clas ă nu
poate s ă existe în absen Ńa claselor de care este dependent ă (figura 5.6.).

Fig. 5.6. – Asociere clasificabil ă
Un alt termen utilizat în conjunctur ă cu cel de asociere este cel de rol , care reprezint ă cap ătul unei
asocieri. Astfel, într-o asociere binar ă fiec ărui cap ăt i se poate atribui un rol (nume), care are un în Ńeles
în contextul aplica Ńiei. Numele unui rol identific ă în mod unic cap ătul respectiv al asocierii. Se
recomand ă utilizarea numelor de roluri în cazul în care asoc ierile sunt între obiectele aceleia și clase.

O asociere poate fi calificată . O asociere calificat ă leag ă dou ă clase de obiecte și un calificator ,
reprezentând un atribut special care reduce efectul multiplicit ăŃii unei asocieri. Dac ă exist ă o asociere
de tip unu la mul Ńi sau mul Ńi la mul Ńi, atunci folosirea unui calificator în partea mul Ńi va identifica în
mod unic obiectul respectiv. De exemplu: între clas a Departament și Angajat exist ă o leg ătur ă de unul
la mai mul Ńi. Deci un departament poate avea unul sau mai mul Ńi angaja Ńi, dar un angajat lucreaz ă
numai într-un singur departament; utilizarea califi catorului nume_angajat reduce asocierea unu la mai
mul Ńi la o asociere unul la unul, întrucât un departame nt și un nume de angajat identific ă unic un
angajat.

Agregarea este o rela Ńie special ă, de tip parteîîntreg (part–whole) sau parteîdin (a-part-of), în care
anumite obiecte reprezentând componente ale unui în treg sunt asociate cu acel obiect, care reprezint ă
întregul, sau altfel spus agregarea este o rela Ńie care leag ă o clas ă ansamblu cu o clas ă component,

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 56 fiind o form ă special ă de asociere, și nu un concept în sine, cu urm ătoarele propriet ăŃi: este tranzitivă
și asimetrică . Deci o clasă agregat este definit ă ca o clas ă a c ărei structur ă const ă din unul sau mai
multe obiecte simple.

Agreg ările pot fi clasificate în trei categorii:
/lozenge6 Agregare fixă : clasa agregat const ă dintr-un num ăr fix de componente, deci agregarea are o
structur ă fix ă (num ărul și tipurile p ărŃilor sunt predefinite). De exemplu un Pătrat are patru
Unghiuri și patru Laturi .
/lozenge6 Agregare variabilă : clasa agregat const ă dintr-un num ăr finit de elemente, dar num ărul de
elemente poate varia. De exemplu, un Act AdiŃional poate avea un num ăr variabil de Servicii .
/lozenge6 Agregare recursivă : con Ńine, direct sau indirect, o instan Ńă a aceluia și tip de agregare. Num ărul
de nivele posibil este nelimitat. De exemplu, un Termen este o generalizare a clasei Expresie , dar
clasa Expresie este format ă din Termeni .

Fig. 5.7. – Rela Ńii de agregare
O posibil ă rafinare a unei asocieri o reprezint ă relaŃia de utilizare care permite accesul clientului
numai la interfa Ńa public ă a furnizorului.

Generalizarea este rela Ńia dintre o clas ă și una sau mai multe versiuni mai rafinate ale ei. C lasa care
se rafineaz ă se nume ște clasă de bază , sau superclasă , iar fiecare versiune mai rafinat ă se nume ște
clasă derivată , sau subclasă . Atributele și opera Ńiile comune unui grup de subclase sunt grupate în
superclas ă și se spune c ă sunt mo ștenite de fiecare subclas ă. Fiecare subclas ă are și propriile atribute și
opera Ńii. Generalizarea poate avea mai multe niveluri (ma ximum 2-3), iar generalizarea și mo ștenirea
sunt tranzitive prin aceste niveluri. Generalizarea este o construc Ńie util ă atât pentru modelarea
conceptual ă cât și pentru implementare și faciliteaz ă modelarea structurând clasele și eviden Ńiind
similitudinile și diferen Ńele între clase. Mo ștenirea opera Ńiilor este util ă în implementare pentru c ă
permite reutilizarea codului.

Fig. 5.8. – Generalizarea

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 57 O caracteristic ă important ă a unui sistem este dat ă de caracterul s ău dinamic, iar pentru descrierea
acestuia se vor utiliza o serie de concepte, care l a rândul lor vor fi folosite pentru realizarea modelului
dinamic al sistemului .
La un moment dat un obiect se afl ă într-o anumit ă stare , reprezentat ă prin mul Ńimea valorilor tuturor
atributelor și leg ăturilor obiectului. Ca urmare a unor stimuli extern i, numi Ńi evenimente , starea unui
obiect poate s ă se schimbe în timp. Pentru fiecare obiect, aceast ă schimbare este reflectat ă de diagrama
dinamic ă a obiectului respectiv. O stare este deci o abstra ctizare a valorilor atributelor și leg ăturilor
unui obiect, care specific ă r ăspunsul unui obiect la un eveniment. Astfel, un obi ect r ămâne într-o stare
atâta timp cât nu apar evenimente externe. Trecerea dintr-o stare în alta, cauzat ă de un eveniment
extern, se nume ște tranziŃie .

Un eveniment este o modificare a contextului, care are loc la u n anumit moment de timp și nu are
durat ă. Dou ă evenimente pot fi legate unul de cel ălalt astfel: un eveniment poate s ă precead ă sau s ă
succead ă logic altui eveniment (deci s ă fie condi Ńionat de acesta), sau cele dou ă evenimente s ă nu fie
condi Ńionate reciproc (ele nu se pot influen Ńa unul pe altul). Despre dou ă evenimente necondi Ńionate se
spune c ă sunt concurente și în acest caz ele pot s ă apar ă simultan. Un eveniment este o transmisie
unidirec Ńional ă de informa Ńie de la un obiect la altul.

O diagramă de stare descrie comportamentul unei singure clase ( modelul dinamic este o colec Ńie de
diagrame de stare, care interac Ńioneaz ă unele cu altele prin evenimentele partajate). Astf el când un
obiect recep Ńioneaz ă un eveniment, starea s ă urm ătoare depinde atât de starea curent ă, cât și de
evenimentul recep Ńionat. Diagrama de stare reflect ă toate st ările posibile ale unui obiect al unei clase,
obiect care poate avea un ciclu de via Ńă finit sau infinit. O diagram ă de stare este un graf ale c ărui
noduri sunt st ările și ale c ărui arce sunt tranzi Ńiile între st ări. Toate tranzi Ńiile din aceea și stare trebuie
să corespund ă unor evenimente diferite. O astfel de diagram ă este reprezentat ă în figura 5.9. O
diagram ă pentru un obiect cu via Ńă finit ă are o stare de pornire (ini Ńial ă) și una de sosire (final ă).

Fig. 5.9. – Diagrama de st ări pentru un automat de scos bani
O condiŃie este o func Ńie boolean ă având drept parametri obiecte. Condi Ńiile pot fi folosite pentru a
stabili momentul când va avea loc o anumit ă tranzi Ńie. O tranzi Ńie condi Ńional ă se execut ă numai atunci
când apare evenimentul și condi Ńia corespunz ătoare este îndeplinit ă.

Diagramele de stare nu specific ă numai evenimentele, ci ele descriu și ce face un obiect, ca r ăspuns la
un eveniment. R ăspunsul obiectelor este descris de opera Ńii, care pot fi de dou ă tipuri:
/lozenge6 Activitatea este o opera Ńie care are o anumit ă durat ă (necesit ă un interval de timp pentru a fi
executat ă). Ea este asociat ă unei stări și se execut ă în starea respectiv ă. O activitate implic ă o
opera Ńie continu ă, ca de exemplu men Ńinerea unei ferestre pe ecran. Reprezentarea unei a ctivit ăŃi
se face, în diagrama de st ări, prin cuvântul do: , urmat de ce se realizeaz ă.
/lozenge6 AcŃiunea este o opera Ńie instantanee. Ea este asociat ă cu un eveniment . Nota Ńia pentru o ac Ńiune
este slash (/) urmat de numele ac Ńiunii care succede evenimentului ce a produs ac Ńiunea.
Simpl ă Cu condi Ńii

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 58 Trebuie reamintit faptul c ă modelul dinamic specific ă secven Ńe permise de transform ări ale obiectelor
din modelul obiectelor. O diagram ă de stare descrie toat ă sau o parte din comportarea unui obiect al
unei clase date. St ările sunt clase de echivalen Ńă ale valorilor atributelor și leg ăturilor unui obiect.
Evenimentele pot fi reprezentate ca opera Ńii în modelul obiectelor. Modelul dinamic al unei c lase este
mo ștenit de subclasele sale, acestea mo ștenind atât st ările, cât și tranzi Ńiile superclasei.
5.2. Limbajul unificat de modelare E UML
UML (Unified Modeling Language ) a fost conceput cu scopul de reuni elementele cel e mai
semnificative ale tuturor metodelor de modelare și analiz ă cunoscute pân ă în acel moment (anul 1994)
și de a furniza un mecanism eficient de dezvoltare a programelor, dar mai ales de a impune o metod ă
unic ă de analiz ă. Aceast ă opera Ńie de unificare prezint ă anumite avantaje și dezavantaje.[Chiorean,
1998]

Avantaje:
/lozenge6 eliminarea unor diferen Ńe de concep Ńie și de nota Ńie;
/lozenge6 eliminarea conceptelor ce nu s-au dovedit viabile și p ăstrarea celor care s-au dovedit utile.
Dezavantaje:
/lozenge6 introducerea inevitabil ă a unui num ăr de noi concepte, sporind astfel complexitatea met odei;
/lozenge6 fiecare metod ă prezentat ă pân ă în acest moment Ńinea cont de anumite particularit ăŃi ale
problemelor, ceea ce nu mai este posibil în noul co ntext.
UML ( Unified Modeling Language ) furnizeaz ă o arhitectur ă pentru analiza și proiectarea obiectual ă
a unui sistem cu unul din limbajele corespunz ătoare pentru specificarea, vizualizarea, construire a și
documentarea sistemului software executat de proiec tant și pentru modelarea afacerilor și a altor
sisteme non-software.

Aceast ă specificare reprezint ă convergen Ńa celor mai bune metode practice utilizate în indus tria
tehnologiei obiectuale. UML este succesorul, am put ea spune cel mai bun pentru limbajele de
modelare obiect, al celor trei metode precedente or ientate obiect, și anume, Booch, OMT și OOSE,
incluzând în plus expresivitate în manipularea prob lemelor de modelare pe care aceste trei modele nu
le utilizeaz ă pe deplin. Unul dintre scopurile principale ale UM L a fost acela de a îmbun ătăŃi situa Ńia
industriei software prin asigurarea interoperabilit ăŃii instrumentelor de modelare vizual ă a obiectului.

Totu și, pentru a permite schimbul corect al modelului in forma Ńional între instrumente, este necesar ă o
conven Ńie în ceea ce prive ște semantica și nota Ńia utilizat ă. În acest scop, UML îndepline ște
urm ătoarele condi Ńii:
/lozenge6 Definirea formal ă a metamodelului comun de analiz ă și proiectare a obiectului (OA&D)
reprezint ă semantica modelului OA&D, care include modele stat ice, modele comportamentale,
modele de utilizare și modele structurale.
/lozenge6 Specifica Ńii IDL ( Interface Definition Language ) pentru mecanisme care s ă asigure
interoperabilitatea modelului între instrumente OA& D. Acest document include un set de
interfe Ńe IDL care ajut ă la crearea unei construc Ńii dinamice și a unei linii transversale de
intersec Ńie a modelului utilizat.
/lozenge6 Nota Ńie conven Ńional ă (human-readable) pentru reprezentarea modelelor OA &D. UML prezint ă o
grafic ă elegant ă pentru a prezenta pe larg semantica sa bogat ă. Nota Ńia este o component ă
esen Ńial ă a model ării OA&D și UML.
Totul a pornit de la OMG ( Object Management Group ) al c ărui obiectiv este de a asigura dezvoltarea
tehnologiei obiectuale și influen Ńarea ei în direc Ńia stabilit ă de OMA ( Object Management
Architecture ), care furnizeaz ă infrastructura conceptual ă pe care toate specifica Ńiile OMG sunt

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 59 bazate. Adoptarea de c ătre OMG a specifica Ńiei UML reduce gradul de confuzie în cadrul industr iei
limbajelor de modelare și permite schimbul reciproc între instrumentele de dezvoltare vizuale utilizate.
5.2.1. Evolușia limbajului UML
Precursori UML : limbajele de modelare orientate obiect au început s ă apar ă la începutul anilor 1970,
și în 1980 existau deja o varietate de metodologii e xperimentale cu diferen Ńe apropiate fa Ńă de analiza
și proiectarea orientat ă obiect. Unele dintre aceste tehnologii au influen Ńat aceste limbaje, printre care
enumer ăm modelarea entitate–relaŃie (Entity-Relationship modeling), SDL ( Specification &
Description Language ) și alte tehnologii. Num ărul acestor limbaje de modelare a crescut în perioa da
1989–1994 de la 10 la mai mult de 50. La mijlocul a nilor 1990, au început s ă apar ă noi variante ale
acestor metode, cel mai reprezentativ fiind modelul Booch’93, dezvoltarea modelului OMT, și Fusion.
Aceste metode încep s ă încorporeze tehnici unele de la altele, și astfel apar metodele OOSE, OMT-2,
și Booch’93 îmbun ătăŃit ă.

UML a fost dezvoltat de Rational Software și partenerii s ăi. Efortul de unificare a început oficial în
octombrie 1994 când Grady Booch și Jim Rumbaugh de la Rational Software Corporation încep
unificarea metodelor Booch și OMT. Prima versiune UML, numit ă Unified Method , ( UML 0.8 ) a
ap ărut în octombrie 1995. În toamna aceluia și an, Ivar Jacobson, și compania lui Objectory, se al ătur ă
companiei Rational; și se încorporeaz ă și metoda OOSE. Ca autori ai celor trei metode Booch ’93,
OMT, și OOSE, Grady Booch, Jim Rumbaugh, și Ivar Jacobson au motivat crearea unui limbaj
unificat de modelare din trei puncte de vedere:
1. Aceste metode au evoluat cu scopul de a fi independ ente unele fa Ńă de altele.
2. Prin unificarea semanticii și nota Ńiei, aceste metode ar putea aduce o anumit ă stabilitate pe pia Ńa
de produse orientate-obiect.
3. Ei sperau ca aceast ă colaborare s ă înl ăture incovenientele celor trei metode.
Efortul lor s-a concretizat în apari Ńia documenta Ńiei pentru variantele UML 0.9 și UML 0.91 , în
perioada iunie–octombrie 1996. Din acest moment în dezvoltarea acestui limbaj și-au depus eforturile
și firmele: Digital Equipment Corp., HP, I-Logix, IB M, ICON Computing, MCI Systemhouse,
Microsoft, Oracle, Rational Software, Texas Instrum ents, Intellicorp și Unisys. Aceast ă colaborare a
condus la realizarea unui limbaj de modelare putern ic, expresiv, foarte bine definit, și cu aplicabilitate
general ă, numit UML.

În ianuarie 1997 IBM & ObjectTime, Platinum Technol ogy, Ptech, Taskon & Reich Technologies, și
Softeam propun separarea RFP ( Request For Proposal – care din 1996 a fost obiectul OMG) de OMG.

Prima versiune, care a fost publicat ă și propus ă aprob ării OMG în ianuarie 1997, a fost UML 1.0 care
cuprindea urm ătoarele documente principale: UML Semantics; UML Su mmary; UML Notation
Guide; UML Process-Specific Extensions, și drept surse secundare urm ătoarele documente: OMA;
CORBA 2.0; Object Analysis & Design RFP-1; Rational Process. OMA, CORBA 2.0 și Object
Analysis & Design RFP-1 au fost utilizate pentru a sus Ńine acordul OMG și a furniza termenul de
obiect distribuit care completeaz ă UML-ul, iar Rational Process pentru a furniza term enii de proces și
arhitectur ă care completeaz ă, de asemenea UML-ul.

Diagrame ini Ńiale care au fost propuse sunt:
/lozenge6 Diagrama cazurilor de utilizare;
/lozenge6 Diagrama claselor;
/lozenge6 Diagrame de comportament:
• Diagrama de stare;
• Diagrama de activitate;
• Diagrama secven Ńial ă;

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 60 • Diagrama de colaborare;
/lozenge6 Diagrame de implementare:
• Diagrama de componente;
• Diagrama de aplica Ńie.
Îmbun ătăŃirile aduse acestei prime variante au condus la apa ri Ńia în iulie 1997 a versiunii UML 1.1 ,
care a fost acceptat ă spre publicare în septembrie 1997, și adoptat ă în 14 noiembrie 1997, devenind
astfel standard OMG.

Drept diagrame au fost propuse cele nou ă diagrame de la versiunea 1.0 cu singura deosebire c ă
diagrama secven Ńial ă și de colaborare au fost grupate în diagramele de in terac Ńiuni.

Documentele necesare a fi parcurse pentru în Ńelegerea primei variante a limbajului, UML 1.1, sun t:
/lozenge6 UML Semantics , acest document define ște semantica utilizat ă de UML (metamodelul UML).
/lozenge6 UML Notation Guide , specific ă sintaxa grafic ă (diagramele) utilizate pentru exprimarea
semanticii folosite de metamodelul UML (prezentarea metodei).
/lozenge6 OCL ( Object Constraint Language ) Specification , define ște sintaxa OCL, semantica, și
gramatica utilizat ă (instrumentul necesar în Ńelegerii limbajului).
Dar pentru în Ńelegerea deplin ă mai trebuiesc parcurse și urm ătoarele documente:
/lozenge6 OA&D CORBAfacility Interface Definition – specific ă o interfa Ńă de interoperabilitate
instrument utilizând CORBA IDL. Acest document spec ific ă interfe Ńele pentru CORBAfacility
pentru Object Analysis & Design, consecvent cu UML v.1.1. OA&D Facility reprezint ă un
depozit pentru modele exprimate în UML. U șurin Ńa (îndemnarea – facility) permite crearea,
memorarea, și manipularea modelelor UML, deoarece permite o var ietate larg ă a capacit ăŃilor de
dezvoltare bazate pe model, incluzând:
• Desenarea modelelor UML în alte nota Ńii și UML;
• Aplicarea unor procese și metode în stilul liniilor directoare;
• Matrici, interog ări, și rapoarte;
• Automatizarea activit ăŃilor dezvolt ării ciclului de via Ńă .
O prim ă directiv ă a OA&D Task Force este de a realiza interoperabili tatea semantic ă între
instrumentele OA&D. Figura urm ătoare descrie mai multe alternative pentru schimbar ea
informa Ńiei de model între instrumente.

Fig. 5.10. – Alternative de model partajat între instrumente OA&D
Repository Dou ă instrumente pot interfa Ńa c ătre acela și depozit și accesa un model de aici. MOF
(MetaObject Facility) poate fi acest depozit. Object
Analysis &
Design
Facility Tool 1
MetaObject Facility
or
Repository Tool 2
Intermediate Stream/File Model Transfer Repository
Model Access read write

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 61 Model Transfer Dou ă instrumente pot în Ńelege acela și format de structur ă și schimba modele
prin aceast ă structur ă, care poate fi un fi șier. RFP face referire la acest format drept “impor t
facility”. Având aceast ă interfa Ńă va fi necesar ă furnizarea unei c ăi pentru instrumente care nu
sunt implementate într-un API (CORBA sau non CORBA) sau mediu de lucru depozit.
Model Access Dou ă instrumente pot schimba modele pe o baz ă detaliu-prin-detaliu. RFP-ul se
refer ă la aceast ă metod ă ca o facilitate de conectivitate “connection facil ity”.
/lozenge6 UML Proposal Summary – face un sumar a propunerii OMG și discut ă rela Ńia UML-ului cu
alte tehnologii, incluzând meta-metamodelul MOF.
Alte documente cuprinse în aceast ă versiune sunt:
/lozenge6 UML Extension for the Objectory Process for Softwar e Engineering;
/lozenge6 UML Extension for Business Modeling.
Principalele deosebiri dintre versiunile UML 1.0 și UML 1.1 erau:
/lozenge6 Cre șterea formalismului;
/lozenge6 Unificarea semantici interac Ńiuni și colabor ării;
/lozenge6 Simplificarea modelului interfe Ńei / tipului / clasei;
/lozenge6 Unificarea semanticilor rela Ńiilor;
/lozenge6 Extinderea semantici managementului modelului, incl uzând modele și subsisteme;
/lozenge6 Extinderea semanticii cazului de utilizare;
/lozenge6 Îmbun ătăŃirea structurii împachet ării;
/lozenge6 Îmbun ătăŃirea transpunerii nota Ńiei c ătre semantic ă.
A urmat în 1998 UML 1.2 ; în 1999 UML 1.3 ; în mai 2001 UML 1.4 ; tot în 2001 UML 1.5 RTF ( Revision
Task Force ); și în 2002 UML 2.0 RFP . Mai trebuie amintit c ă din 1994 și pân ă la 17 ianuarie 1997 s-
au înregistrat 5 propuneri distincte, dintre care c ele mai importante au fost UML (Unified Modeling
Language), OML (Open Modeling Language) și Object Time (IBM). În martie 2003 a fost
standardizat ă versiunea UML 1.5 , numit și Unified Modeling Language Specification.

Specificarea UML 1.3 cuprinde:
/lozenge6 UML Summary
/lozenge6 UML Semantics
/lozenge6 UML Notation Guide
/lozenge6 UML Standard Profiles:
• Software Development Processes
• Business Modeling
/lozenge6 UML CORBAfacility Interface Definition
/lozenge6 UML XML Metadata Interchange DTD
/lozenge6 Object Constraint Language
Principalele deosebiri dintre UML 1.2 ( și UML 1.1) și UML 1.3 sunt:
/lozenge6 Modificarea rela Ńiilor folosite între cazurile de utilizare. UML 1.1 avea dou ă rela Ńii între cazurile
de utilizare <<uses>> și <<extends>>, amândou ă fiind de fapt stereotipuri ale rela Ńiei de
generalizare. UML 1.3 are trei rela Ńii: <<include>>, care este un stereotip al rela Ńiei de
dependen Ńă , și ea înlocuie ște utilizarea lui <<uses>>; rela Ńia de generalizare, și <<extends>>, un
stereotip al rela Ńiei de dependen Ńă .
/lozenge6 Diagrama de activitate. Modific ările se refer ă la utilizarea barelor de sincronizare, care sunt d e
bifurca Ńie și de reuniune, la concuren Ńa dinamic ă etc.
Din anul 2002 versiunea UML 2.0 este propus ă pentru evaluare (proposals under evaluation). În
aceast ă versiune exist ă 13 diagrame și cuprinde 4 componente:
/lozenge6 UML Infrastructure
/lozenge6 UML Superstructure
/lozenge6 OCL (Object Constraint Language)

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 62 /lozenge6 UML Diagram Interchange
Dintre firmele care utilizeaz ă UML drept standard în procesele de dezvoltare și produc Ńie, care acoper ă
o gam ă larg ă de discipline, precum modelarea afacerilor, manage mentul resurselor, analiz ă și
proiectare, programare, enumer ăm: Data Access Corporation, Electronic Data Systems Corporation,
Enea Data, Hewlett-Packard Company, IBM Corporation , I-Logix, ICON Computing, IntelliCorp and
James Martin & Co (James Odell), OAO Technology Sol ution,ObjectTime Limited, Oracle
Corporation, PLATINUM Technology Inc., Rational Sof tware (Grady Booch, Ivar Jacobson,Jim
Rumbaugh), SAP, SOFTEAM, Sterling Softwrae, Taskon, Unisys Corporation.

UML este îmbun ătăŃit în continuare prin intermediul unei echipe, cond use de Cris Kobryn, formate din
personalit ăŃi precum: James Odell, Dilhar DeSilva, Martin Griss , Eran Gery, Karin Palmkvist, Guus
Ramackers, Bran Selic, Sridhar Iyengar, Gunnar Over gaard, și Jos Warmer. De asemenea, Grady
Booch, Ivar Jacobson, și Jim Rumbaugh lucreaz ă în echip ă pentru îmbun ătăŃirea acestuia, datorit ă
experien Ńei lor în acest domeniu. Exist ă de asemenea contribu Ńii individuale cum ar fi: Peter Coad,
Tim Harrison, Bertrand Meyer, Bill Premerlani, Ed Y ourdon, Oliver Wiegert, și mul Ńi al Ńii.

O succint ă evolu Ńie a UML-ului este prezentat ă în figura 5.11.

Fig. 5.11. – Evolu Ńia limbajului de modelare UML
UML a fost selectat drept standard al limbajelor de modelare orientate-obiect ( OOML – Object
Oriented Modeling Language ) de c ătre OMG în noiembrie 1997, și este utilizat de dezvoltatorii de
produse software.

Aceast ă specificare reprezint ă convergen Ńa celor mai bune metode practice utilizate în indus tria
tehnologiei obiectuale și care au avut succes în modelarea sistemelor mari și complexe.

UML este un limbaj pentru specificarea, construirea , vizualizarea și documentarea unui sistem
software complex.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 63
Un programator anonim a spus “1 bitmap = 1 megaword ”. Din aceast ă afirma Ńie putem s ă tragem
concluzia cât de semnificativ ă este utilizarea unor metode, limbaje pentru care a u fost create diverse
instrumente de lucru, care redau descrierea sistemu lui prin intermediul diferitelor nota Ńii grafice, mult
mai sugestive, și care u șureaz ă enorm munca în echip ă, reducând în acela și timp perioada pentru
analiza și proiectarea sistemului. [Kobryn, 2001]

Sfera de întindere a limbajului unificat de modelar e este:
/lozenge6 În primul rând și cel mai important, UML este un limbaj care reune ște conceptele utilizate de
Booch, OMT și OOSE. Rezultatul este un limbaj de modelare unic, comun și în mare m ăsur ă
ușor de folosit pentru utilizatorii acestor metode, p recum și altele.
/lozenge6 În al doilea rând, UML extinde sfera de cuprindere a ceea ce se dore ște a fi f ăcut cu metodele
existente.
/lozenge6 În al treilea rând, UML se bazeaz ă pe limbaje standard de modelare și nu pe un proces standard.
Așa cum sugereaz ă chiar numele limbajului, sprijinul oferit de limba j vizeaz ă în primul rând
construirea modelelor.
Acestea ar fi no Ńiunile care Ńin de UML, dar în afara acestora ar mai fi de ad ăugat urm ătoarele: UML
este un limbaj vizual de modelare , dar care nu are preten Ńia de a fi un limbaj de programare vizual, el
este un limbaj universal pe care dezvoltatorii îl p ot utiliza pentru descrierea sistemelor lor. De ce este
un limbaj ? Deoarece UML utilizeaz ă o sintax ă (reprezint ă elementele limbajului care sunt asamblate
în expresii) și o semantic ă (în Ńelesurile expresiilor sintactice) pentru a descrie sistemul. Pentru
descrierea sistemului dezvoltatorii folosesc anumit e nota Ńii grafice standard. Astfel, UML surprinde și
descrie în limbaj natural sistemul . Ceea ce nu rezolv ă UML este problema schimbului de date, care
poate fi rezolvat cu Microsoft Repository . Pentru programarea codului se poate utiliza unul din
limbajele orientate obiect cele mai cunoscute.

UML dispune la ora actual ă de mai multe instrumente prin intermediul c ărora toat ă munca este
executat ă prin intermediul calculatorului. Instrumentele și interoperabilitatea dintre ele este
dependent ă de defini Ńia semanticii și a nota Ńiei: UML define ște un metamodel semantic, și nu un
instrument de interfa Ńă , memorare, sau execu Ńie a modelului.
5.2.2. Noșiuni generale despre UML
UML reprezint ă o arhitectur ă bazat ă pe 4 niveluri de abstractizare (figura 5.12.). Cel e patru niveluri de
abstractizare sunt: metaEmetamodelul (reprezint ă infrastructura pentru o arhitectur ă de metamodele),
metamodelul (reprezint ă o instan Ńă a unui meta-metamodel și define ște semantica necesar ă pentru
reprezentarea modelelor aplica Ńiei cu ajutorul UML), modelul (reprezint ă o instan Ńă a metamodelului)
și obiecte utilizator (reprezint ă o instan Ńă a unui model, utilizat ă pentru descrierea unui domeniu de
informa Ńie specific).

Metamodelul UML este un model logic și nu unul fizic (de implementare) și are în componen Ńa sa trei
pachete logice: Elemente de comportament (Behavioral Elements), Elemente de bază (Foundation)
și Mecanisme generale (Model Management), dup ă cum se poate observa din figura 5.13.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 64

Fig. 5.12. – Arhitectura metamodelului UML

Fig. 5.13. – Structura pachetului UML
În cadrul fiec ărui pachet, elementele unui model sunt definite în urm ătorii termeni:
• Sintaxa abstractă : este prezent ă în diagrama claselor UML și prezint ă metamodelul UML,
conceptele sale (metaclase), rela Ńiile și constrângerile. Diagrama prezint ă reguli foarte bine
formulate, în special cerin Ńele legate de multiplicitatea leg ăturilor, și când, sau nu, instan Ńa
unui subconstructor particular trebuie s ă fie ordonat ă. Pentru fiecare metaclas ă, atributele sale
sunt enumerate împreun ă cu o scurt ă explica Ńie. În plus, numele rolurilor asocierilor conectate
la metaclas ă sunt scrise la capetele fiec ărei asocieri.
• Reguli foarte bine formate ( reguli de corectitudine – wellîformedness rules ): sunt definite
regulile și constrângerile impuse modelelor corecte. Semantic a static ă a metaclaselor UML,
exceptând multiplicitatea și constrângerile, sunt definite ca un set de invari ante ale unei
instan Ńe a metaclasei.
• Semantica : specific ă modelele utilizate pentru structura și comportamentul obiectului,
prezentat în mod normal în limba englez ă.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 65

Fig. 5.14. – Diagrama claselor UML,
structurarea în pachete și subpachete
Figura 5.14. arat ă dependen Ńele între elementele modelului UML din diferite pac hete. Modelele
structurale (modele statice) accentueaz ă structura obiectelor într-un sistem, incluzând cla sele lor,
interfe Ńele, atributele și rela Ńiile. Modelele de comportament (modele dinamice) accentueaz ă
comportamentul obiectelor într-un sistem, incluzând metodele, interac Ńiunile, colabor ările și starea lor
istoric ă. Semantica este definit ă într-o modalitate independent ă de limbajele de implementare. O
implementare a semanticii, f ără o interfa Ńă consistent ă și alegerile implement ării, nu garanteaz ă
interoperabilitatea instrumentului.

Alegerea modelelor și diagramelor are o profund ă influen Ńă asupra problemei supuse analizei și
modului în care solu Ńia corespunde problemei. Din acest motiv:
/lozenge6 Fiecare sistem complex va trebui supus unei analize din mai multe puncte de vedere.
/lozenge6 Fiecare model poate fi exprimat la diferite nivele de fidelitate.
/lozenge6 Cel mai bun model este cel legat de realitate.
Un model reprezint ă o colec Ńie de obiecte (Classes, Packages, Actors, Use Cases, Components și
Nodes), relaŃii (Association, Dependencies și Generalization) și diagrame . Din punctul de vedere al
unui model, UML define ște diferite tipuri de diagrame grafice, al c ăror num ăr a crescut de la 9 tipuri
standard, varianta UML 1.1, pân ă la 13 tipuri, varianta UML 2.0.
/lozenge6 Diagrama cazurilor de utilizare (use case diagram).
/lozenge6 Diagrama claselor (class diagram).
/lozenge6 Diagrama obiectelor (object diagram).
/lozenge6 Diagrame de comportament (behaviour diagrams):
• diagrama de stare , numit ă și diagrama graficelor de stare (statechart diagram) ;
• diagrama de activitate (activity diagram);
• diagrame de interacŃiuni (interaction diagrams):
/rhombus4 diagrama secvenŃială (succesiune) (sequence diagram);
/rhombus4 diagrama de colaborare (collaboration diagram);
/lozenge6 Diagrame de implementare (implementation diagrams):
• diagrama de componente (component diagram);
• diagrama de aplicaŃie (de dezvoltare ) (deployment diagram).
Aceste diagrame furnizeaz ă perspective multiple asupra sistemului analizat, p rivind analiza și/sau
dezvoltarea sa. Leg ătura dintre modele și diagrame este ilustrat ă în figura 5.15.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 66

Fig. 5.15. – Modele, vederi și diagrame
De ce este UML un limbaj de modelare și nu o metodologie ? Modelarea este proiectarea apl ica Ńiilor
software înainte de implementarea codului în diferi te limbaje de programare. O metodologie este
alc ătuit ă din dou ă componente: un limbaj de modelare și un proces de modelare care arat ă succesiunea
de pa și care trebuie parcur și pentru realizarea modelului.

Un limbaj de modelare trebuie s ă includ ă:
/lozenge6 Elementele modelului – conceptele de modelare fundamentale și semantic ă.
/lozenge6 NotaŃia – interpretarea vizual ă a elementelor modelului. Nota Ńia UML este un element esen Ńial
pentru UML care permite comunicarea între membrii e chipei de lucru. Acceptarea nota Ńiei este
op Ńional ă, dar semantica nu va fi foarte semnificativ ă dac ă nu este bine exprimat ă. Acceptarea
nota Ńiei este definit ă în cadrul fiec ărui tip de diagram ă UML: cazuri de utilizare, clase, grafice de
stare, de activitate, secven Ńial ă, de componente și de dezvoltare.
/lozenge6 Linii directoare (guidelines) – utilizarea sintagmelor (expresiilor ) în interiorul produsului.
Scopurile principale ale UML sunt urm ătoarele:
/lozenge6 Să furnizeze utilizatorilor un limbaj de modelare viz ual expresiv pentru dezvoltarea și
specificarea semnifica Ńiei modelului.
/lozenge6 Mecanisme extensibile și specializate pentru a extinde conceptele de baz ă.
/lozenge6 Suport pentru specifica Ńii care sunt independente de un limbaj de programar e particular și
dezvoltarea proceselor.
/lozenge6 Furnizeaz ă o baz ă formal ă pentru în Ńelegerea limbajului de modelare.
/lozenge6 Încurajeaz ă cre șterea vânz ărilor de instrumente obiect.
/lozenge6 Suport ă concepte de dezvoltare de nivel superior precum co mponente, colabor ări, frameworks și
modele.
/lozenge6 Integreaz ă cele mai bune practici existente la ora actual ă.
5.2.3. Concepte UML
Unul din scopurile model ării vizuale este de a în Ńelege arhitectura aplica Ńiei. Membrii echipei de lucru
pot în Ńelege aceast ă arhitectur ă a aplica Ńiei prin intermediul diagramelor de modelare UML. P entru
în Ńelegerea conceptelor UML sunt utilizate trei tipuri principale de blocuri constructive:
/lozenge6 Elementele.
/lozenge6 Rela Ńiile.
/lozenge6 Diagramele.
precum și:
/lozenge6 Mecanisme extensibile: stereotipuri, constrângeri, și valori etichetate (tagged value).
Conceptele cele mai utilizate sunt cele preluate de la cei trei care au contribuit la apari Ńia limbajului de
modelare UML, Booch, Rumbaugh și Jacobson. Cu toate acestea, anumite elemente cons tructive sunt
preluate de la alte metode apar Ńinând altor speciali ști din domeniul analizei și proiect ării sistemelor:
Shlaer & Mellor, Martin & Odell, Wirfs & Brock, Fus ion, Meyer, Harel, Gamma etc.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 67

Fig. 5.16. – Contribu Ńii la dezvoltarea UML
Elementele UML
Elementul este constituentul atomic al unui model. Într-un m etamodel elementul reprezint ă cea mai
înalt ă metaclas ă în ierarhia metaclaselor, fiind o clas ă abstract ă. Exist ă dou ă metasubclase: Element de
Model ( ModelElement ) și Element de Prezentare ( PresentationElement ), care la rândul lor sunt
construc Ńii abstracte. Elementele UML pot fi grupate astfel: structurale (statice), comportamentale
(dinamice), de grupare și suplimentare. Un tip special de ModelElement este clasificatorul , care este
un element ce descrie caracteristicile structurale și de comportament, dintre care amintim: clasa,
interfa Ńa, tipuri de date, nodul, componenta, semnalul, act orul, caz de utilizare și subsistem.

Elementele structurale
Elementele structurale reprezint ă p ărŃile statice ale unui model, reprezentând elemente c onceptuale
sau fizice și care sunt componente ale pachetelor Elemente de bază (clasa, interfa Ńa, nodul,
componenta, tipuri de date) și o parte din Elemente de comportament (colaborarea și caz de
utilizare).

În continuare se vor prezenta acele aspecte ale ele mentelor structurale care nu au fost descrise în
prezentarea conceptelor de baz ă ale tehnologiei orientate obiect.

O clasă reprezint ă o descriere a unui set de obiecte care au în comun acelea și atribute, opera Ńii,
metode, rela Ńii și semantici. Scopul unei clase este de a declara o colec Ńie de metode, opera Ńii și
atribute care descriu complet structura și comportamentul obiectelor. Clasele pot fi conside rate drept
obiecte, dar ele sunt metaîobiecte , nu obiecte ale lumii reale. Obiectele care descri u clasele au
propriile lor caracteristici, deci au clase proprii numite metaclase . Fiecare obiect instan Ńiat dintr-o
clas ă con Ńine propriul set de valori corespunz ător atributelor și suport ă opera Ńiile declarate în
descrierea complet ă a clasei. Fiecare clas ă trebuie s ă aib ă un nume care s ă o disting ă de celelalte clase.

O clasă activă este o clas ă ale c ărei obiecte au propriile fire de control (posed ă unul sau mai multe
procese sau cursuri ale prelucr ării și care poate ini Ńia o activitate de control) și al c ăror comportament
este concurent cu alte elemente. În caz contrar, av em de-a face cu o clasă pasivă .

UML suport ă urm ătoarele tipuri de clase:
/lozenge6 Clasă abstractă – este acea clas ă care nu poate avea instan Ńe directe.
/lozenge6 Clasă rădăcină – este acea clasă care nu are p ărin Ńi (str ămo și), deci nu poate fi o subclas ă a altor
clase.
/lozenge6 Clasă frunză – este acea clas ă care nu poate avea are copii (descenden Ńi), deci nici o alt ă clas ă nu
poate fi o subclas ă a clasei.
O clas ă poate implementa un set de interfe Ńe pentru a specifica setul de opera Ńii pe care le furnizeaz ă
mediului s ău. O subclasă poate ad ăuga noi atribute și/sau opera Ńii fa Ńă de caracteristicile claselor
ascendente, caz în care spunem c ă avem de-a face cu o extensie a clasei. De asemenea , o subclas ă
poate restrânge atributele claselor ascendente, caz în care spunem c ă avem de-a face cu o restric Ńie a
clase, limitându-le tipul la un singur subtip al ti pului respectiv. Fiecare generalizare trebuie s ă se fac ă

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 68 dup ă o singur ă proprietate. Dac ă o clas ă poate fi rafinat ă dup ă mai multe dimensiuni distincte și
independente se realizeaz ă generalizări multiple .

O interfaŃă reprezint ă un set de opera Ńii, care împreun ă definesc un serviciu oferit de un clasificator
(clas ă sau component ă) și care descrie comportamentul vizibil extern al ace stuia, integral sau par Ńial.
Un clasificator poate oferi mai multe servicii, cee a ce înseamn ă c ă el poate realiza mai multe interfe Ńe
și mai mul Ńi clasificatori pot realiza aceea și interfa Ńă .

Un nod este un obiect fizic run-time (exist ă în timpul execu Ńiei) și care reprezint ă o resurs ă de calcul
având în general memorie și mai multe procese capabile de prelucrare.

O componentă reprezint ă o parte fizic ă a unui sistem, care implementeaz ă pachete și permite
realizarea unui set de interfe Ńe; ea reprezint ă o implementare a unui sistem, incluzând cod softwa re
(surse, binare, sau executabile) sau echivalente pr ecum script-uri sau fi șiere de comand ă.

Un tip de date reprezint ă un tip ale c ărui valori nu au identitate. Tipurile de date inclu d tipuri
primitive (precum integer sau string), tipuri enume rate etc.

O colaborare define ște o interac Ńiune și descrie modul în care diferi Ńi clasificatori și alte elemente
(asocierile clasificatorilor) se utilizeaz ă la realizarea unui anumit comportament particular (un task
particular); o clas ă poate participa la mai multe colabor ări, iar scopul unei colabor ări este de a
specifica modalitatea în care o opera Ńie sau un clasificator, cum ar fi un caz de utiliza re, este realizat ă
de un set de clasificatori și asocieri.

Un caz de utilizare este folosit pentru a defini comportamentul unui s istem f ără a dezv ălui structura
intern ă a entit ăŃii. Fiecare caz de utilizare specific ă descrierea unei succesiuni de ac Ńiuni pe care
sistemul le poate realiza, interac Ńionând cu actorii sistemului, pentru a ob Ńine un rezultat observabil de
un anumit actor.

În afara celor 7 elemente structurale de baz ă, UML mai utilizeaz ă și alte elemente structurale, printre
care pot fi men Ńionate:
/lozenge6 Actor , este un element definit în subpachetul Use Cases al pachetul Behavioral Elements. Un
actor define ște un set coerent al rolurilor pe care utilizatorii unei entit ăŃi (sistem, subsistem, clas ă)
îl poate executa atunci când interac Ńioneaz ă cu entitatea respectiv ă. Instan Ńa unui actor este un
utilizator specific care interac Ńioneaz ă cu entitatea, iar în cazul în care entitatea este un sistem
actorii reprezint ă atât utilizatori umani cât și alte sisteme. Actorii pot face parte din interior ul sau
din afara entit ăŃii cu care interac Ńioneaz ă; ei pot comunica cu un set al cazurilor de utiliza re, pot
avea un set de interfe Ńe și pot avea rela Ńii de generalizare cu al Ńi actori. Un actor este un obiect
care opereaz ă asupra altor obiecte dar asupra c ăruia nu poate opera alt obiect (de regul ă, obiect
activ).
/lozenge6 Semnal , este un element definit în subpachetul Common Beh avior al pachetului Behavioral
Elements. Printre caracteristicile de baz ă ale unui semnal se impun: un semnal este o specifi care a
unui stimul asincron comunicat între instan Ńe; un semnal poate fi ata șat unui clasificator, ceea ce
înseamn ă c ă instan Ńa clasificatorului va fi capabil ă s ă primeasc ă acest semnal; semnalul este un
element generalizabil și este definit independent de clasele care utilizea z ă semnalul. Atunci când
un semnal este cauzat de o caracteristic ă de comportament specific ă apari Ńiei unei erori, se spune
că s-a produs o excepŃie .
Elemente comportamentale reprezint ă p ărŃile dinamice ale modelelor UML și ele sunt definite în
pachetul Behavioral Elements (acest pachet specific ă comportamentul dinamic al modelelor).
Principalele elemente comportamentale sunt: interac Ńiunea și ma șina de st ări.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 69 O interacŃiune este un comportament care con Ńine un set de mesaje schimbat între un set de obiec te
într-un anumit context, definit de ClassifierRoles, pentru a îndeplini un anumit obiectiv.
Caracteristicile unei interac Ńiuni sunt definite în subpachetul Collaborations, i ar în realizarea unei
interac Ńiuni sunt implicate și alte elemente:
/lozenge6 Mesajul , este definit în subpachetul Collaborations și define ște o comunicare particular ă între
instan Ńele specificate de o interac Ńiune. El specific ă rolurile instan Ńelor expeditorului și
receptorului, în a șa fel încât rolul asocierii va specifica leg ătura de comunicare. Mesajul este
ata șat unei ac Ńiuni, specificând instruc Ńiunea care, atunci când este executat ă, determin ă
comunicarea specificat ă.
/lozenge6 AcŃiunea , este o metaclas ă abstract ă definit ă în subpachetul Common Behavior, fiind o
specificare a unei instruc Ńiuni executabile care formeaz ă o abstractizare a unei proceduri de
calcul, având drept rezultat o modificare a st ării modelului, care poate fi realizat prin trimiter ea
unui mesaj c ătre un obiect sau prin modificarea unei leg ături.
/lozenge6 Legătura , definit ă în subpachetul Common Behavior, reprezint ă o instan Ńă a unei rela Ńii de
asociere și define ște o conexiune între instan Ńe.
O mașină de stare reprezint ă o specifica Ńie care descrie succesiunile de st ări ale unui obiect sau
interac Ńiuni în timpul ciclului de via Ńă , ca r ăspuns la evenimente, împreun ă cu r ăspunsurile sale la
acele evenimente. Comportamentul este modelat ca o parcurgere a unui grafic al nodurilor de stare
interconectate la una sau mai multe arcuri de tranz i Ńii asociate unor st ări ale instan Ńelor de evenimente.
În timpul acestei parcurgeri, ma șina de stare execut ă o serie de ac Ńiuni asociate diferitelor elemente ale
ma șinii de stare. Caracteristicile și modul de comportare a unei ma șini de st ări este definit în
subpachetul State Machines. La rândul ei, o ma șin ă de st ări implic ă un num ăr de alte elemente:
/lozenge6 Starea este o metaclas ă abstract ă care modeleaz ă o situa Ńie în timp ce alt ă condi Ńie invariant ă o
sus Ńine. Totodat ă poate reprezenta o condi Ńie a unui model dinamic, precum procesul realiz ării
unei activit ăŃi. În timpul execu Ńiei unui eveniment o stare poate fi activ ă (este o intrare ca rezultat
a unei tranzi Ńii) sau inactiv ă (exist ă ca rezultat al unei tranzi Ńii).
/lozenge6 TranziŃia este o rela Ńie direct ă între un nod de stare surs ă și un nod de stare destina Ńie. Ea poate fi
parte a unei tranzi Ńii compuse, care duce ma șina de stare dintr-o stare de configurare în alta, ca
rezultat al unui eveniment particular.
/lozenge6 Evenimentul este generat ca rezultat al unei ac Ńiuni fie din interiorul sistemului sau din mediul
înconjur ător sistemului.
/lozenge6 AcŃiunea (ca r ăspuns la o tranzi Ńie).
Cele dou ă elemente (interac Ńiunea și ma șina de stare) sunt conectate la diferite elemente s tructurale:
clase, colabor ări, obiecte.

Elementele de grupare reprezint ă p ărŃile organiza Ńionale ale modelelor UML, definite în pachetul
Model Management, care cuprinde urm ătoarele elemente:
/lozenge6 Pachetul (package ) este un mecanism cu scop general pentru organizar ea elementelor în grupuri
de elemente structurale, elemente comportamentale s au chiar alte elemente de grupare. Un pachet
reprezint ă de fapt o grupare a elementelor unui model.
/lozenge6 Modelul reprezint ă o abstractizare a unui sistem fizic, cu un anumit scop, specificând sistemul
fizic din diferite puncte de vedere ale abstractiz ării, el reprezentând de fapt o descriere complet ă a
unui sistem dintr-o anumit ă perspectiv ă (particular ă). Scopul avut în vedere va determina
elementele care vor fi considerate (incluse în mode l) semnificative și nesemnificative pentru
model. Un model va con Ńine o ierarhie de elemente care împreun ă descriu sistemul fizic. De
asemenea, va con Ńine și un set de elemente care reprezint ă mediul înconjur ător al sistemului, cum
ar fi actorii împreun ă cu interac Ńiunile lor, precum rela Ńiile de dependen Ńă , generaliz ări și
constrângeri.
/lozenge6 Subsistemul este o grupare a elementelor de model care reprezi nt ă un element comportamental al
unui sistem fizic. Un subsistem ofer ă interfe Ńe și are opera Ńii proprii.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 70 Elemente suplimentare , printre care enumer ăm:
/lozenge6 Note – pentru formularea constrângerilor și altor comentarii.
/lozenge6 Comentariu – este o nota Ńie ata șat ă unui element sau unui set de elemente ale modelulu i.
/lozenge6 CerinŃe – pentru specificarea comportamentului dorit din p erspectiva exterioar ă modelului.

Relașii UML
O relaŃie reprezint ă o conexiune între elementele modelului, fiind un t ermen conven Ńional (abstract),
fără specifica Ńii semantice. Rela Ńiile suportate de UML sunt de: asociere, dependen Ńă , realizare (sau de
flux), și generalizare.

O relaŃie de asociere este o rela Ńie structural ă care descrie un set de leg ături, o legătură fiind o
conexiune între obiecte. Asocierea declar ă o conexiune între instan Ńele clasificatorilor asocia Ńi,
constând din cel pu Ńin dou ă termina Ńii de asociere, fiecare specificând un clasificator conectat și un set
de propriet ăŃi care trebuie s ă fie realizat pentru ca fiecare rela Ńie s ă fie valid ă (corect ă). De asemenea,
se poate specifica rolul pe care fiecare clasificator îl îndepline ște în rela Ńia de asociere; multiplicitatea
pentru fiecare cap ăt al asocierii, care va specifica câte (num ărul) instan Ńe ale clasificatorului aflat la
sfâr șitul asocierii pot fi asociate cu o singur ă instan Ńă a clasificatorului surs ă (aflat la începutul
asocierii). Unei rela Ńii de asociere i se poate ata șa și un calificator , care reprezint ă un atribut special
care reduce multiplicitatea efectiv ă a rela Ńiei de asociere, rezultând o asociere cu calificator .

În UML asocierile pot fi de trei feluri:
/lozenge6 Asociere ordinară – reprezint ă rela Ńia de asociere cea mai utilizat ă, prin intermediul c ăreia doi
calificatori sunt conecta Ńi.
/lozenge6 Agregare de compoziŃie (composite aggregate) – este o form ă puternic ă a agreg ării. Ea
presupune c ă o instan Ńă (un obiect) poate face parte la un moment dat numa i dintr-un singur
obiect compus și c ă obiectul compus este singurul responsabil pentru c aracterul p ărŃilor sale.
Dac ă obiectul compus este distrus, el trebuie s ă distrug ă toate p ărŃile sale componente.
/lozenge6 Agregare partajată (shared aggregate) – partea poate fi inclus ă în mai multe agreg ări și
propriet ăŃile sale se pot modifica în timp.
Agregarea este un tip special al rela Ńiei de asociere, reprezentând o rela Ńie structural ă între un întreg și
părŃi ale acestuia (rela Ńie parte-întreg), deci ea leag ă o clas ă ansamblu cu o clas ă component. Numai
asocierile binare pot fi agregări .

O relaŃie de dependenŃă este o rela Ńie semantic ă între dou ă elemente prin care o modificare în unul
din elemente, numit element independent, poate afec ta semanticile celuilalt element, numit element
dependent. O dependen Ńă este un termen conven Ńional pentru o rela Ńie alta decât asocierea,
generalizarea, realizarea (flux), sau alte metarela Ńii (precum rela Ńia între un clasificator și una din
instan Ńele sale).

Într-un metamodel, o dependen Ńă este o rela Ńie direct ă între un client (sau clien Ńi) și un furnizor (sau
furnizori), stabilind dependen Ńa clientului fa Ńă de furnizor. Tipurile rela Ńiilor de dependen Ńă suportate
de UML sunt:
/lozenge6 Abstractizarea – este o rela Ńie de dependen Ńă care leag ă dou ă elemente, sau seturi de elemente,
reprezentând acela și concept la nivele diferite de abstractizare, sau din puncte de vedere diferite.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 71 /lozenge6 Legătura ( binding ) – o conexiune între elementele din cadrul aceluia și model. O leg ătur ă trebuie
să aib ă un furnizor (desemneaz ă elementul care nu este afectat de o modificare) și un client. Un
element furnizor poate participa în mai multe rela Ńii de leg ătur ă c ătre diferi Ńi clien Ńi. Un element
client poate participa numai într-o singur ă rela Ńie de leg ătur ă cu un furnizor. O leg ătur ă este o
rela Ńie de dependen Ńă unde furnizorul este un model și clientul reprezint ă instan Ńierea modelului
care îndepline ște substituirea parametrilor modelului.
/lozenge6 Utilizarea – este o rela Ńie în care un element are nevoie de un alt element (sau set de elemente)
pentru implementarea sa complet ă. O utilizare este o rela Ńie de dependen Ńă în care clientul
necesit ă prezen Ńa furnizorului, de exemplu: o clas ă apeleaz ă o opera Ńie a unei alte clase
(<<call>>); o metod ă având un argument al altei clase (<<create>>); o m etod ă dintr-o clas ă
instan Ńiaz ă alt ă clas ă (<<instantiate>>).
/lozenge6 Permisiunea – este o rela Ńie care acord ă unui element (client) dreptul s ă acceseze alte elemente
(furnizori). Clientul prime ște permisiunea s ă fac ă referire la con Ńinutul furnizorului. Furnizorul
trebuie s ă fie o asociere sau un clasificator.
O relaŃie de realizare este o rela Ńie semantic ă între clasificatori, în care un clasificator speci fic ă un
contract a c ărui realizare e garantat ă de un alt clasificator. Este o rela Ńie între dou ă versiuni ale unui
obiect sau între un obiect și o copie a sa. Exemple de rela Ńii de realizare: între interfe Ńele și clasele sau
componentele care le realizeaz ă, între cazurile de utilizare și colabor ările prin care acestea se
realizeaz ă.

O relaŃie de generalizare este o rela Ńie de clasificare între mai multe elemente generale (un element
generalizabil este un element care poate participa într-o rela Ńie de generalizare și / sau de specializare)
și mai multe elemente specifice. O generalizare este o rela Ńie de generalizare-specializare în care
obiectele elementului specializat (fiu sau copil) p artajeaz ă structura și comportamentul obiectelor
elementului generalizat (p ărinte). Generalizarea între clase implic ă substituirea. Astfel, dac ă o clas ă
este specificat ă ca root , ea nu poate fi o subclas ă a altei clase (nu poate avea str ămo și). În mod similar,
dac ă ea este specificat ă drept clasă frunză (leaf), nici o alt ă clas ă nu poate fi o subclas ă a clasei (nu
poate avea descenden Ńi).

În afara acestor rela Ńii, în UML mai sunt definite dou ă tipuri de rela Ńii care sunt utilizate în conjunctur ă
cu cazurile de utilizare (use cases):
/lozenge6 RelaŃia de extindere (extend), definit ă în subpachetul Use Cases din pachetul Behavioral
Elements, este o rela Ńie prin care comportamentul și structura unui caz de utilizare poate fi
îmbun ătăŃit cu comportamentul și structura unui alt caz de utilizare. Rela Ńia are loc numai dac ă
condi Ńia care o înso Ńește este îndeplinit ă.
/lozenge6 RelaŃia de includere (include), definit ă în subpachetul Use Cases din pachetul Behavioral
Elements, semnific ă faptul c ă un caz de utilizare con Ńine comportament definit în alt caz de
utilizare. Rela Ńia de includere este o rela Ńie între dou ă cazuri de utilizare.
5.2.4. Diagramele UML
Înainte de a trece la prezentarea diagramelor utili zate de UML, trebuie specificat c ă exist ă trei
perspective care trebuie utilizate în desemnarea di agramelor (sau a oric ărui model) [Cook&Daniels,
1994]:
/lozenge6 Conceptuală : în acest caz se utilizeaz ă o diagram ă care reprezint ă conceptele din domeniul
sistemului supus analizei. Aceste concepte vor avea leg ătur ă cu clasele pe care le implementeaz ă,
dar nu este o reprezentare direct ă. Modelul este proiectat f ără a Ńine seama de software-ul care îl
va implementa și este în general independent de limbaj.
/lozenge6 SpecificaŃia : în acest moment aten Ńia este îndreptat ă c ătre software, dar de fapt c ătre interfe Ńele
software-ului și nu c ătre implementarea propriu zis ă. Dezvoltarea orientat ă obiect pune un mare
accent pe diferen Ńa între interfa Ńă (tip) și implementare (clas ă). Tipurile reprezint ă o interfa Ńă care

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 72 poate avea mai multe implement ări datorit ă mediului de implementare, caracteristicilor de
performan Ńă etc.
• Implementarea : în momentul implement ării se utilizeaz ă clasele.
Dup ă cum s-a ar ătat în versiunii UML 2.0 exist ă 13 diagrame (în loc de 9), împ ărŃite în 3 categorii:
1. Diagrame de structură : descriu structura static ă a aplica Ńiei.
2. Diagrame de comportament : descriu aspecte diferite ale comportamentului din amic.
3. Diagrame de interacŃiune : reprezint ă un subset al diagramelor de comportament care
accentueaz ă interac Ńiunile dintre obiecte.
Diagrame Descriere
1. Diagrama de activitate Ilustrează procesele de a faceri, incluzând fluxul de
date.
2. Diagrama claselor Arată o colecŃie de elemente ale modelului static,
precum clasele și tipul lor.
3. Diagrama de comunicaŃie Arată instanŃe ale clase lor, relaŃiile de interacŃiune
dintre ele, și fluxul mesajelor dintre ele. Diagram a se
concentrează pe organizarea structurală a obiectelo r
care trimit și primesc mesaje. La vechile versiuni era
denumită diagrama de colaborare.
4. Diagrama de componente Ilustrează componentele c are compun întreprinderea,
sistemul, sau aplicaŃia.
5. Diagrama de structură
compusă Ilustrează structura internă a unui clasificator
(clasă, componentă, caz de utilizare), inclusiv pun ctele
de interacŃiune ale clasificatorului cu alte părŃi ale
sistemului.
6. Diagrama de aplicaŃie Arată execuŃia arhitecturi i de sistem. Aceasta
include noduri, componente hardware sau medii de
execuŃie software, precum și produse middleware.
7. Diagrama de concluzionare a
interacŃiunilor
(interaction overview) O variantă a diagramei de activitate care face o
privire de ansamblu a fluxului de control în interi orul
sistemului sau procesului de afaceri. Fiecare nod /
activitate din interiorul diagramei poate reprezent a
altă diagramă de interacŃiune.
8. Diagrama de obiecte Ilustrează obiectele și rela Ńiile lor la un anumit
moment de timp, în mod normal un caz special fie a
diagramei claselor sau a diagramei de comunicaŃie.
9. Diagrama de pachete Arată cum elementele de mode l sunt organizate în
pachete, precum și dependenŃele dintre pachete.
10. Diagrama secvenŃială Modelează logica secvenŃia lă, în fapt ordonarea în
timp a mesajelor dintre clasificatori.
11. Diagrama mașinilor de stare Descrie stările unui obiect, precum și tranziŃiile
dintre stări.
12. Diagrama de sincronizare
(timing) Ilustrează modificarea în stare sau condiŃie a
instanŃei unui clasificator sau rol în timp. Este
utilizată pentru a arăta modificarea stării unui ob iect
în timp ca răspuns la evenimente externe.
13. Diagrama cazurilor de
utilizare Arată cazurile de utilizare, actorii, și relaŃiile dintre
ele.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 73 O diagram ă poate con Ńine colec Ńii ale urm ătoarelor tipuri de obiecte: actori (diagrama cazuri lor de
utilizare), clase (diagrama claselor), componente ( diagrama componentelor sau de aplica Ńie), noduri
(diagrama de aplica Ńie), pachete (diagrama claselor sau pachetelor), ca zuri de utilizare (diagrama
cazurilor de utilizare), st ări (diagrama de activitate sau de stare), obiecte ( diagrama obiectelor, de
colaborare, secven Ńial ă, componentelor, de aplica Ńie, sau de activitate), semnale (diagrama de
activitate), asocieri (diagrama claselor, cazurilor de utilizare, sau obiectelor), generaliz ări (diagrama
claselor, pachetelor, sau cazurilor de utilizare), dependen Ńe (diagrama claselor, cazurilor de utilizare,
componentelor, sau de aplica Ńie), tranzi Ńii (diagrama de activitate sau de stare), interac Ńiuni (diagrama
de colabor ări), mesaje (diagrama secven Ńial ă) etc.
Diagrama Claselor (Class Diagram)
Diagrama claselor reprezint ă tehnica central ă de modelare pe care se bazeaz ă toate modelele orientate
obiect. Diagrama claselor este un grafic al clasifi catorilor conecta Ńi prin relaŃii statice care exist ă
între clasificatori precum asocierea, compozi Ńia (agregarea de compozi Ńie), delega Ńia (permisiunea) și
generalizarea. O astfel de diagram ă mai poate con Ńine interfe Ńe, pachete, rela Ńii, și chiar instan Ńe,
precum obiecte și leg ături. Un nume mai corect pentru aceast ă diagram ă ar fi “diagrama de structur ă
static ă”.

Obiectivul principal al acestei diagrame este să de finească clasele de bază împreună cu
caracteristicile utilizate în alte diagrame dinamic e .

Diagrama claselor este utilizat ă pentru:
/lozenge6 Modelarea clasele de baz ă (caracteristicile ar ătate în alte diagrame dinamice).
/lozenge6 Modelarea colabor ărilor (specificarea claselor și a rela Ńiilor acestora).
/lozenge6 Modelarea schemei logice a bazei de date.
/lozenge6 Modelarea vocabularului sistemului (specificarea ab strac Ńiilor și a responsabilit ăŃilor acestora).
Diagrama claselor poate fi implementat ă ca o clasa actual ă, care este utilizat ă în limbajele suportate de
clas ă, și care cuprinde: clase , interfe Ńe, note și legarea notelor , text , rela Ńii de dependen Ńă , de
generalizare , de asociere , de realizare și de agregare (agregarea de compozi Ńie), colabor ări .

No Ńiunile de clas ă, interfa Ńă , colaborare și rela Ńiile utilizate au fost explicate în subcapitolele
precedente. Pentru în Ńelegerea corect ă a acestei diagrame mai este necesar ă explicarea altor concepte
utilizate în proiectarea ei. Ceea ce trebuie sublin iat este faptul c ă un clasificator declar ă o colec Ńie de
caracteristici, precum: atribute, metode, și opera Ńii. Numele fiec ărui clasificator este unic și reprezint ă
o metaclasă abstractă .

Un atribut reprezint ă un nume din interiorul unui clasificator și care descrie un domeniu de valori pe
care le poate lua instan Ńele clasificatorului, putând avea o valoare ini Ńial ă. De asemenea, un atribut
poate avea una din urm ătoarele propriet ăŃi, care se refer ă la posibilitatea de modificare a valorii, dup ă
ce obiectul a fost creat:
/lozenge6 changeable (modificabil) – în acest caz nu este impus ă nici o restric Ńie asupra valorii atributului;
/lozenge6 addOnly – valabil numai pentru atributele cu multiplicitat e mai mare decât unu; o valoarea odat ă
ad ăugat ă nu mai poate fi ștears ă sau modificat ă;
/lozenge6 frozen – valoarea atributului nu poate fi modificat ă dup ă ini Ńializarea obiectului.
O operaŃie este un serviciu care poate fi cerut de c ătre un obiect pentru a efectua un comportament; ea
este o semn ătur ă, care descrie parametrii actuali care sunt posibil i (inclusiv posibile valori returnate).
O opera Ńie poate fi polimorfică , ceea ce înseamn ă c ă, într-o ierarhie de clase, pot fi specificate oper a Ńii
cu aceea și semn ătur ă la nivele diferite în ierarhie dar cu implement ări diferite.

O opera Ńie poate avea una din urm ătoarele propriet ăŃi (se refer ă la simultaneitatea apelurilor
concurente c ătre aceea și clas ă pasivă – este o instan Ńă a unui clasificator cu atributul isActive = False):

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 74 /lozenge6 isQuery – se refer ă și la o metod ă (opera Ńia și metoda reprezint ă caracteristici dinamice ale unui
element al modelului) și arat ă dac ă o execu Ńie a unei opera Ńii, sau a unei metode, schimb ă sau nu
starea sistemului. Dac ă are valoarea True starea sistemului r ămâne neschimbat ă;
/lozenge6 sequential (secven Ńial ă) – apelurile trebuie coordonate în a șa fel încât numai unul poate apela o
instan Ńă (pe orice opera Ńie secven Ńial ă), la un moment dat; în caz contrar semantica și integritatea
sistemului nu pot fi garantate;
/lozenge6 guarded (prudent ă) – apeluri multiple se pot produce simultan c ătre o instan Ńă , dar numai un apel
este permis s ă înceap ă; celelalte opera Ńii sunt blocate pân ă când realizarea primei opera Ńii este
terminat ă complet. O opera Ńie de acest tip este utilizat ă pentru secven Ńierea apelurilor în cazul
fluxurilor multiple ale controlului;
/lozenge6 concurrent (concurent ă) – apeluri multiple se pot produce simultan c ătre o instan Ńă , fiecare
dintre ele putând fi realizate în paralel.
O opera Ńie poate avea și parametri care pot fi utiliza Ńi în specificarea opera Ńiilor, semnalelor,
mesajelor, evenimentelor etc., și fiecare parametru include un nume, tip și direc Ńia comunic ării. Pentru
fiecare parametru al unei opera Ńii se poate specifica direc Ńia astfel:
/lozenge6 in – reprezint ă un parametru de intrare care nu poate fi modificat ;
/lozenge6 out – reprezint ă un parametru de ie șire, care poate fi modificat pentru a comunica info rma Ńii c ătre
alte elemente;
/lozenge6 inout – reprezint ă un parametru de intrare care poate fi modificat;
/lozenge6 return – reprezint ă o valoare returnat ă unui apel.
O metodă reprezint ă o implementare a unei opera Ńii, și specific ă algoritmul sau procedura care
produce efectele unei opera Ńii.

Unul dintre cele mai importante detalii care poate fi specificat pentru atributele și opera Ńiile unui
clasificator este vizibilitatea acestora. Vizibilitatea unei caracteristici (atrib ut sau opera Ńie) specific ă
când aceasta poate fi, sau nu, utilizat ă de un alt clasificator.

În UML se pot specifica urm ătoarele nivele de vizibilitate:
/lozenge6 public (public) – orice alt clasificator, care are vizibi litate, poate utiliza atributul sau opera Ńia
respectiv ă;
/lozenge6 protected (protejat) – orice descendent al clasificatorului poate utiliza atributul sau opera Ńia;
/lozenge6 private (privat) – numai clasificatorul însu și poate utiliza atributul sau opera Ńia.
Un alt detaliu care poate fi specificat drept o car acteristic ă (atribut sau opera Ńie) a unui clasificator este
scopul (scope), care poate fi:
/lozenge6 instance (instan Ńă ) – fiecare instan Ńă a clasificatorului con Ńine propria valoare a caracteristicii;
/lozenge6 classifier (clasificator) – exist ă o singur ă valoare pentru toate instan Ńele unui clasificator.
Multiplicitatea clasei specific ă num ărul de instan Ńe ale clasei. Multiplicitatea se aplic ă și la nivel de
atribut.

Pentru rela Ńiile de dependen Ńă (abstractizarea, leg ătura, utilizarea și permisiunea) între clasele și
obiectele din diagrama claselor se pot defini urm ătoarele stereotipuri:
/lozenge6 RelaŃia de abstractizare :
• <<derive>> – specific ă o rela Ńie de derivare de-a lungul elementelor unui model c are sunt în
mod normal de acela și tip; se poate utiliza când se dore ște modelarea rela Ńiei între dou ă
atribute sau dou ă asocieri, dintre care una este concret ă iar cealalt ă este conceptual ă;
• <<realize>> – specific ă o rela Ńie de realizare între un element (sau elemente) num it furnizor
(respectiv furnizori) și un alt element (sau elemente) numit client (respe ctiv clien Ńi) pe care le
implementeaz ă;

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 75 • <<refine>> – specific ă o rela Ńie de rafinare între elementele modelului la nivele semantice
diferite, precum analiza și proiectarea (sursa este la un grad mai fin de abs tractizare decât
Ńinta);
• <<trace>> – reprezint ă o rela Ńie de urm ărire între elementele modelului, sau seturi de elem ente,
care reprezint ă acela și concept în modele diferite;
/lozenge6 RelaŃia de permisiune :
• <<access>> – este un tip de rela Ńie de dependen Ńă între dou ă rela Ńii de asociere sau doi
clasificatori, indicând c ă p ărŃile publice ale destina Ńiei sunt accesibile sursei pachetului;
• <<friend>> – este un tip de rela Ńie de dependen Ńă a c ărei surs ă este un element, precum o
opera Ńie, clas ă, sau pachet și a c ărui destina Ńie este un element dintr-un pachet diferit, precum
o opera Ńie, o clas ă, sau pachet; acord ă accesul sursei la destina Ńie indiferent de modul de
declarare a vizibilit ăŃii;
• <<import>> – este un tip de rela Ńie de dependen Ńă între dou ă asocieri, sau doi clasificatori,
indicând c ă p ărŃile publice ale destina Ńiei sunt ad ăugate sursei.
/lozenge6 RelaŃia de utilizare :
• <<call>> – sursa este o opera Ńie și destina Ńia este tot o opera Ńie;
• <<create>> – clasificatorul client creeaz ă instan Ńe ale clasificatorului furnizor;
• <<instantiate>> – opera Ńiile pentru client creeaz ă instan Ńe ale furnizorului;
• <<send>> – sursa este o opera Ńie și destina Ńia este un semnal (sursa trimite un semnal).

Fig. 5.17. – Diagrama claselor
Pentru rela Ńia de asociere mai pot fi specificate:
/lozenge6 DirecŃia de navigare de la obiectele de un tip la obiecte de alt tip.
/lozenge6 Vizibilitatea asocierii – specific ă vizibilitatea unui sfâr șit al asocierii din punctul de vedere al
clasificatorului de la cel ălalt cap ăt al asocierii; valorile posibile sunt: public, pro tected și private.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 76 /lozenge6 Calificator – reprezint ă un atribut al asocierii ale c ărui valori parti Ńioneaz ă setul de obiecte legate
la un obiect printr-o asociere; dac ă nu are nici o valoare rela Ńia de asociere nu este calificat ă.
/lozenge6 Specificator de interfaŃă – pentru limitarea interfe Ńei la contextul asocierii.
De asemenea, UML permite definirea de:
/lozenge6 Clase de asocieri – reprezint ă o asociere care este de asemenea o clas ă, ea nu poate exista în
afara asocierilor care o determin ă.
/lozenge6 Constrângeri care este o condi Ńie semantic ă sau o restric Ńie exprimat ă în text prin intermediul
unui limbaj natural. Unele constrângeri sunt defini te de UML, altele pot fi definite de utilizator.
Constrângerea este o afirmare și nu un mecanism executabil. Ea indic ă o restric Ńie care trebuie s ă
fie impus ă pentru descrierea corect ă a unui sistem. Constrângerile pot fi aplicate atât rela Ńiei de
asociere cât și atributelor unei clase.
/lozenge6 InterfeŃe . O interfa Ńă este o colec Ńie de opera Ńii utilizate pentru a specifica un serviciu al unei
clase. Interfa Ńa poate participa la rela Ńii de dependen Ńă , de asociere, de generalizare și de
realizare.
Diagrama Obiectelor (Object Diagram)
Diagrama obiectelor eviden Ńiaz ă un set de obiecte și rela Ńiile cu alte obiecte la un moment dat și poate
fi considerat ă un caz special al diagramelor claselor sau al diag ramei de colabor ări, fiind de fapt o
instan Ńă a unei diagrame de clase, ea fiind un instantaneu al unei st ări al unui sistem la un moment dat.
Ea con Ńine: obiecte , legături , eventual note și constrângeri . Aceast ă diagram ă este utilizat ă pentru
vizualizarea, specificarea, construirea și documentarea structurii obiectelor.

Modelarea structurii obiectelor presupune:
/lozenge6 Identificarea mecanismului de modelat (o anumit ă func Ńie sau comportamentul unei p ărŃi a
sistemului).
/lozenge6 Pentru fiecare mecanism, se identific ă clasele, interfe Ńele și alte elemente care particip ă la aceast ă
colaborare.
/lozenge6 Se consider ă un scenariu prin acest mecanism; se determin ă fiecare obiect care particip ă la
mecanism.
/lozenge6 Selectarea obiectelor care au responsabilit ăŃi de nivel înalt pentru fluxul de lucr ări (workflow).
/lozenge6 Identificarea precondi Ńiilor st ărilor ini Ńiale și postcondi Ńiilor st ărilor finale.
/lozenge6 Specificarea activit ăŃilor și ac Ńiunilor începând cu starea ini Ńial ă.
/lozenge6 Eviden Ńierea tranzac Ńiilor care conecteaz ă aceste activit ăŃi și ac Ńiuni.
/lozenge6 Eventual, eviden Ńierea obiectelor importante implicate în fluxul de lucr ări, cu eviden Ńierea
schimb ării valorilor.
Modelarea opera Ńiilor obiectelor presupune:
/lozenge6 Colectarea abstrac Ńiilor implicate în opera Ńii (parametri, atribute ale claselor).
/lozenge6 Identificarea precondi Ńiilor st ării ini Ńiale și postcondi Ńiilor st ării finale.
/lozenge6 Specificarea activit ăŃilor și ac Ńiunilor începând cu starea ini Ńială.
/lozenge6 Folosirea ramific ării dac ă este necesar.
/lozenge6 Folosirea bifurc ării și reunirii pentru specificarea fluxurilor de contro l paralele.
Diagrama cazurilor de utilizare (Use Case Diagram)
Aceast ă diagram ă este utilizat ă în faza de analiz ă a sistemului și a cerin Ńelor utilizatorului și arat ă
actorii (utilizator sistem sau sistem extern) și cazurile de utilizare ale sistemului împreun ă cu rela Ńiile
lor. Cazurile de utilizare reprezint ă func Ńionalitatea unui sistem sau a unui clasificator, pr ecum un
subsistem sau o clas ă. Prin utilizarea acestei diagrame, utilizatorii și dezvoltatorii pot u șor ad ăuga și
modifica cerin Ńele utilizatorului.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 77 Diagrama cazurilor de utilizare este un graf al act orilor, un set al cazurilor de utilizare, posibil u nele
interfe Ńe, și rela Ńiile dintre aceste elemente. Rela Ńiile sunt de asociere între actori și cazurile de
utilizare, generalizări între actori și generalizări , extensii , și includeri între cazuri de utilizare.
Cazurile de utilizare pot fi op Ńional incluse într-un dreptunghi care va reprezenta grani Ńa (interfa Ńa)
sistemului con Ńinut.

Diagrama cazurilor de utilizare se folose ște pentru modelarea aspectelor dinamice ale sistemu lui și
anume pentru modelarea comportamentului unui sistem , unui subsistem sau unei clase. O astfel de
diagram ă con Ńine: cazuri de utilizare , actori , relaŃii de dependenŃă , de generalizare și de asociere
și se utilizeaz ă pentru modelarea contextului sistemului (specificarea actorilor și în Ńelegerea rolului
lor) și pentru modelarea cerinŃelor sistemului (CE trebuie s ă fac ă sistemul, și nu CUM).

Modelarea contextului sistemului presupune:
/lozenge6 Identificarea actorilor.
/lozenge6 Organizarea actorilor într-o ierarhie de generaliza re / specializare.
/lozenge6 Popularea diagramei cu actorii identifica Ńi și specificarea c ăilor de comunicare între fiecare actor
și cazurile de utilizare ale sistemului.

Fig. 5.18. – Diagrama cazurilor de utilizare
Modelarea cerinŃelor sistemului presupune:
/lozenge6 Stabilirea contextului sistemului prin identificare a actorilor.
/lozenge6 Stabilirea pentru fiecare actor a comportamentului cerut sau a șteptat din partea sistemului.
/lozenge6 Specificarea cazurilor de utilizare pe baza comport amentelor comune.
/lozenge6 Identificarea de noi cazuri de utilizare care sunt utilizate de altele.
/lozenge6 Modelarea cazurilor de utilizare, a actorilor și a rela Ńiilor între ei într-o diagram ă a cazurilor de
utilizare.
O diagram ă a cazurilor de utilizare bine structurat ă este acea diagram ă care:
/lozenge6 Este centrat ă pe comunicarea unui aspect al viziunii statice a c azurilor de utilizare ale sistemului.
/lozenge6 Con Ńine numai acele cazuri de utilizare și actori care sunt esen Ńiali pentru în Ńelegerea aspectului
analizat.
/lozenge6 Prevede detalii consistente cu nivelul de abstracti zare (numai ceea ce este esen Ńial pentru
în Ńelegere).

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 78 Diagramele de InteracŃiuni (Interaction Diagrams)
Diagrama de interac Ńiuni reprezint ă un termen generic care este aplicat mai multor tip uri de diagrame
care subliniaz ă interac Ńiunea dintre obiecte. Diagramele de interac Ńiuni sunt utilizate în cazul în care se
dore ște reflectarea comportamentului mai multor obiecte dintr-un singur caz de utilizare. În func Ńie de
criteriul care se are în vedere, aceste diagrame su nt de dou ă tipuri:
/lozenge6 Diagrama secvenŃială care eviden Ńiaz ă ordonarea în timp (secven Ńialitatea) a mesajelor.
/lozenge6 Diagrama de colaborare eviden Ńiaz ă organizarea structural ă a obiectelor care trimit și primesc
mesaje (arat ă rela Ńiile dintre instan Ńe).
Diagramele de interac Ńiune con Ńin: obiecte , legături , mesaje și eventual constrângeri .
Diagrama secvenŃială (Sequence Diagram)
Arat ă fluxul dinamic al mesajelor diferitelor obiecte di n sistem. Obiectivul principal al acestei
diagrame este acela de a exprima fluxul de mesaje a l obiectelor în timp secvenŃial . Diagrama
secven Ńial ă arat ă interac Ńiunea obiectelor aranjate în timp secven Ńial. În particular, ea arat ă obiectele
care particip ă la o interac Ńiune și succesiunea mesajelor care sunt schimbate. O diag ram ă secven Ńial ă
poate exista într-o form ă generic ă (descrie toate scenariile posibile) și într-o form ă de exemplu
(descrie un scenariu actual).

Modelarea fluxului controlului prin ordonarea în ti mp a mesajelor presupune:
/lozenge6 Stabilirea contextului interac Ńiunii (sistem, subsistem, opera Ńie, sau clas ă, sau un scenariu al unui
caz de utilizare sau colaborare).
/lozenge6 Identificarea obiectelor care au un rol în ac Ńiune.
/lozenge6 Stabilirea pentru fiecare obiect a faptului dac ă persist ă prin întreaga interac Ńiune; pentru obiectele
create și distruse în timpul interac Ńiunii trebuie s ă se indice explicit, prin mesaj, acest lucru.
/lozenge6 Pentru fiecare mesaj începând cu primul (care ini Ńiaz ă ac Ńiunea) și continuând cu celelalte în
ordinea succesiunii, se prezint ă propriet ăŃile (parametrii).
/lozenge6 Eventual, timpul și spa Ńiul cerut, pentru fiecare mesaj.
/lozenge6 Eventual, precondi Ńii sau postcondi Ńii pentru fiecare mesaj.

Fig. 5.19. – Diagrama secven Ńial ă

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 79 Pentru a eviden Ńia fluxul complet al controlului se pot utiliza mai multe diagrame secven Ńiale.

Diagrama secven Ńial ă are dou ă dimensiuni: una vertical ă, care reprezint ă timpul și una orizontal ă, care
reprezint ă diferite obiecte.
Diagrama de colaborare (Collaboration Diagram)
La fel ca și diagrama secven Ńial ă, diagrama de colaborare arat ă caracteristica dinamic ă a sistemului.
Amândou ă diagramele sunt identice, în ceea ce prive ște informa Ńia intern ă a diagramei, dar diagrama
de colaborare pune un accent mai mare pe colaborare a dintre obiectele sistemului decât pe succesiunea
în timp, specific ă diagramei secven Ńiale. Deci în func Ńie de obiectivul urm ărit, se va alege una din
urm ătoarele diagrame: secven Ńial ă sau de colaborare.

Diagrama de colaborare arat ă interac Ńiunile din interiorul structurii unui model, utiliz ând fie
clasificatori și asocieri sau instan Ńe și leg ături. O diagram ă de colaborare prezint ă o colaborare, care
con Ńine un set de roluri ale obiectelor, sau poate prez enta o interac Ńiune, care define ște un set de
mesaje specifice ei.

Fig. 5.20. – Diagrama de colaborare
Modelarea controlului prin organizare presupune:
/lozenge6 Stabilirea contextului interac Ńiunii (sistem, subsistem, opera Ńie, sau clas ă, sau un scenariu al unui
caz de utilizare sau colaborare).
/lozenge6 Identificarea obiectelor care joac ă rol în ac Ńiune.
/lozenge6 Stabilirea propriet ăŃilor ini Ńiale pentru fiecare obiect; dac ă starea sau rolul unui obiect se schimb ă
semnificativ în timpul interac Ńiunii, se plaseaz ă un obiect duplicat în diagram ă care se
actualizeaz ă cu noile valori și se conecteaz ă printr-un anumit mesaj.
/lozenge6 Specificarea leg ăturilor între obiecte prin care pot trece mesajele: leg ăturile asocierii sau alte
leg ături (global, local).
/lozenge6 Se începe cu mesajul care ini Ńiaz ă interac Ńiunea și se ata șeaz ă fiecare mesaj subsecvent conform
leg ăturilor între obiecte.
/lozenge6 Eventual, timpul și spa Ńiul cerut, pentru fiecare mesaj.
/lozenge6 Eventual, precondi Ńii sau postcondi Ńii pentru fiecare mesaj.
Diagrama de Stare
Diagrama de stare este una din diagramele prin inte rmediul c ărora se eviden Ńiaz ă realizarea cazurilor
de utilizare. Este folosit ă în situa Ńia în care se dore ște modelarea unui obiect care este utilizat în mai
multe cazuri de utilizare. Se folose ște pentru modelarea comportamentului unei interfe Ńe, unei clase
sau unei colabor ări și eviden Ńiaz ă comportamentul orientat-eveniment al unui obiect. Arat ă starea
intern ă și modificarea st ărilor obiectelor clasei specificate, fiecare stare posibil ă a obiectului putând fi
exprimat ă cu ajutorul acestei diagrame.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 80 O diagram ă de stare este un graf care reprezint ă o ma șin ă de st ări ar ătând fluxul controlului de la o
stare la alta și va con Ńine: stări , mașini de stare , tranziŃii . Diagrama de stare se utilizeaz ă pentru
modelarea unui anumit aspect dinamic al sistemului în contextul sistemului ca întreg, unui subsistem
sau unei clase. Se poate folosi pentru modelarea un ui scenariu din diagrama cazurilor de utilizare.

O ma șin ă de st ări este un comportament care arat ă succesiunea de st ări prin care trece un obiect pe
durata sa de via Ńă ca r ăspuns la evenimente, precum și r ăspunsurile la aceste evenimente. În mod
normal, aceast ă diagram ă este utilizat ă pentru descrierea comportamentului claselor, dar p oate de
asemenea s ă descrie și comportamentul altor entit ăŃi precum: cazuri de utilizare, actori, subsisteme,
opera Ńii sau metode.

Diagrama de stare se folose ște pentru modelarea obiectelor reactive și presupune:
/lozenge6 Selectarea contextului (clas ă, caz de utilizare, sistem).
/lozenge6 Selectarea st ărilor ini Ńiale ale obiectelor.
/lozenge6 Ordonarea par Ńial ă a st ărilor stabile în durata de via Ńă a obiectelor.
/lozenge6 Decide evenimentele care pot declan șa o tranzi Ńie de la o stare la alta.
/lozenge6 Ata șeaz ă ac Ńiuni la aceste tranzi Ńii și/sau la aceste st ări.
/lozenge6 Verific ă dac ă toate st ările pot fi atinse printr-o combina Ńie de evenimente.
/lozenge6 Verific ă secven Ńele de evenimente a șteptate și r ăspunsurile lor.

Fig. 5.21. – Diagrama de stare
Diagrama de Activitate (Activity Diagram)
Cu ajutorul acestei diagrame este exprimat ă tranzi Ńia activit ăŃilor. Este utilizat ă în special atunci când
este necesar ă eviden Ńierea leg ăturii fiec ărui serviciu sau a mai multor procese paralele.

Diagrama de activitate este o diagram ă de tip flowchart (organigram ă) care eviden Ńiaz ă fluxul
controlului de la o activitate la alta. O activitat e rezult ă dintr-o anumit ă ac Ńiune (apelul altei opera Ńii,
trimiterea unui semnal, crearea sau distrugerea unu i obiect) sau evaluarea unei expresii care schimb ă
starea sistemului sau întoarce o valoare. Diagrama de activitate este o variant ă a unei ma șini de st ări în
care st ările reprezint ă performan Ńa ac Ńiunilor sau subactivit ăŃilor.

Diagrama de activitate con Ńine: stări ale activit ăŃilor și st ări ale ac Ńiunilor, tranziŃii , obiecte .

St ările activit ăŃilor pot fi descompuse și necesit ă un interval de timp pentru a fi îndeplinite, compa rativ
cu st ările ac Ńiunilor care necesit ă timp de execu Ńie nesemnificativ și nu se pot descompune. Pentru

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 81 obiectele implicate în fluxul controlului se poate eviden Ńia rolul, starea și schimbarea valorilor
atributelor.

Fig. 5.22. – Diagrama de activitate
Diagrama de activitate poate fi utilizat ă pentru:
/lozenge6 Modelarea workflow (activit ăŃi a șa cum sunt v ăzute de actorii care colaboreaz ă cu sistemul).
Aceast ă modelare presupune:
• selectarea obiectelor care au responsabilit ăŃi de nivel înalt pentru workflow;
• identificarea precondi Ńiilor st ărilor ini Ńiale și postcondi Ńiilor st ărilor finale;
• specificarea activit ăŃilor și ac Ńiunilor începând cu starea ini Ńial ă;
• eviden Ńierea tranzi Ńiilor care conecteaz ă aceste activit ăŃi și ac Ńiuni;
• eventual, eviden Ńierea obiectelor importante implicate în workflow, cu eviden Ńierea schimb ării
valorilor.
/lozenge6 Modelarea opera Ńiilor – flowchart . Aceast ă modelare presupune:
• colectarea abstrac Ńiilor implicate în opera Ńii (parametrii, atribute ale claselor);
• identificarea precondi Ńiilor st ării ini Ńiale și postcondi Ńiilor st ării finale;
• specificarea activit ăŃilor și ac Ńiunilor începând cu starea ini Ńial ă;
• folosirea ramific ării dac ă este necesar;
• folosirea bifurc ării și reunirii pentru specificarea fluxurilor de contro l paralele.
Diagramele de Implementare
Diagramele de implementare arat ă aspecte ale implement ării, incluzând cod surs ă și implementarea
run-time. Aceste diagrame se prezint ă sub dou ă forme:
/lozenge6 Diagrama de componente . Diagrama de componente arat ă: structura codului, structura fizic ă a
codului bazat pe componenta de cod actual ă. Diagrama de componente define ște care clase vor fi
incluse în mai multe fi șiere și care fi șiere vor fi incluse în mai multe module. Totodat ă ea arat ă
dependen Ńele componentelor software, incluzând codul surs ă al componentelor, codul binar al
componentelor, și componentele executabile.
/lozenge6 Diagrama de aplicaŃie . Arat ă structura fizic ă a sistemului hardware și software. Aceast ă
diagram ă arat ă configurarea elementelor de procese run-time și componente software, procese și
obiecte.
Utilizarea diagramelor UML depinde de perspectiva d in care este analizat sistemul software. Deoarece
în dezvoltarea sistemului sunt implicate persoane c u calific ări diferite (utilizatori finali, anali ști,
proiectan Ńi, programatori, etc.), arhitectura unui sistem poa te fi descris ă utilizând: viziunea cazurilor
de utilizare, viziunea proiect ării, viziunea proceselor, viziunea implement ării. Pentru fiecare din aceste

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 82 viziuni se pot folosi anumite diagrame pentru evide n Ńierea aspectelor statice și anumite diagrame
pentru eviden Ńierea aspectelor dinamice, la nivelul de detaliu ce rut de fiecare caz în parte.

Fig. 5.23. – Diagrama de componente

Fig. 5.24. – Diagrama de aplica Ńie
Perspectivele din care este analizat sistemul și num ărul de diagrame utilizate depind de gradul de
complexitate al sistemului și de natura acestuia.

De exemplu, pentru modelarea unei aplica Ńii simple, implementabile pe un singur calculator, sunt
necesare numai primele dou ă viziuni. [V ătui, 2000]
Tabelul nr.1 – Diagramele utilizate în cazul unei aplica Ńii simple
Aspectele statice Aspectele dinamice Viziunea
Diagrama cazurilor de utilizare Cazurilor de utili zare
Diagrama claselor Diagrama interacŃiunilor Proiectă rii
Pentru sisteme complexe, implement ările în mediu distribuit, se pot utiliza toate tipu rile de diagrame.

Principalele îmbunătăŃiri aduse de UML fa Ńă de celelalte modele prezentate sunt urm ătoarele:
/lozenge6 Separarea rela Ńiilor structurale (asociere, generalizare, agregare ) de rela Ńiile semantice (rela Ńii de
dependen Ńă , de realizare).
/lozenge6 Simplificarea nota Ńiilor pentru rela Ńiile semantice utilizând aceea și simbolizare cu etichete diferite
în func Ńie de tipul rela Ńiei.
/lozenge6 Extinderea no Ńiunii de clasificatori (folosit ă de toate metodele analizate pentru conceptul de
obiect) pentru urm ătoarele concepte: interfa Ńă , tip de date, semnal, component ă, nod, caz de
utilizare, subsistem.

Proiectarea sistemelor informatice de gestiune
Analiza și proiectarea orientată obiect E 83 /lozenge6 Utilizarea aceluia și tip de diagram ă în etape diferite ale dezvolt ării sistemului.
/lozenge6 Oferirea de recomand ări pentru întocmirea diagramelor.
/lozenge6 Oferirea de criterii de verificare a corectitudinii model ării.
Pentru a u șura munca de analiz ă și proiectare a sistemelor, precum și pentru o analiz ă și o planificare
mai corect ă a procesului de dezvoltare a produsului software, diferite firme, precum Microsoft,
Rational sau OMG au început s ă investeasc ă tot mai mult în activit ăŃile legate de metodologiile de
analiz ă și proiectare de software.

Aceste instrumente, numite instrumente de modelare vizuale orientate obiect ( OOVMT – Object
Oriented Visual Modeling Tool ), sunt utilizate pentru automatizarea elabor ării diagramelor din cadrul
diferitelor metodologii utilizate în proiectarea si stemelor informatice.

În momentul de fa Ńă majoritatea firmelor mari utilizeaz ă UML drept limbaj de modelare pentru
sistemele software. Din acest motiv s-a sim Ńit necesitatea ca acesta s ă fie înglobat într-un proces
unificat care s ă furnizeze o modalitate de elaborare riguroas ă a sarcinilor, Ńinând cont de faptul c ă se
pune un mare accent pe lucru în echip ă, mai ales pentru proiectele mari. Deoarece UML nu este
complet (reprezint ă o nota Ńie de modelare standard industrial ă), mai sunt utilizate și alte tehnici
suplimentare, care includ:
/lozenge6 Modelarea interfe Ńei utilizator (diagrame de control a interfe Ńei utilizator).
/lozenge6 Modelarea datelor.
/lozenge6 Reguli de afaceri.
/lozenge6 Constrângeri etc.

Proiectarea sistemelor informatice de gestiune
Metode de proiectare a bazelor de date E 84 Capitolul 6
Metode de proiectare a bazelor de date
Avu Ńia cea mai important ă pentru o organiza Ńie o reprezint ă informa Ńia. F ără existen Ńa informa Ńiilor o
organiza Ńie nu ar mai putea exista, iar pentru a suprave Ńui aceste informa Ńii trebuiesc utilizate corect,
pentru a se putea ob Ńine rezultate care s ă conduc ă la alegerea celei mai bune solu Ńii pentru
prosperitatea acesteia. Pentru ca acest lucru s ă fie posibil de realizat, aceste informa Ńii trebuie stocate,
triate (filtrate) și analizate în func Ńie de necesit ăŃile ap ărute într-un anumit moment dat. Cea mai bun ă
alegerea pentru ca aceste informa Ńii s ă fie coerente, și s ă nu fie pierdute, sau distruse, în mod
inten Ńionat sau nu, este stocarea acestora în diverse baz e de date. De re Ńinut este citatul lui Alvin
Tofler „…, iar informa Ńia acumulat ă, o parte a avu Ńiei na Ńionale”.

Se știe c ă un sistem informa Ńional cuprinde totalitatea resurselor care permit c olectarea, administrarea,
controlul și propagarea informa Ńiilor într-o organiza Ńie. Atunci când prelucrarea datelor se efectueaz ă
prin intermediul calculatoarelor, acest sistem va c uprinde urm ătoarele componente:
/lozenge6 baza de date;
/lozenge6 elementele software ale bazei de date;
/lozenge6 software de aplica Ńie;
/lozenge6 elementele hardware ale calculatorului;
/lozenge6 personalul care utilizeaz ă și dezvolt ă sistemul.
Dintre aceste componente baza de date constituie componenta fundamental ă a sistemului
informa Ńional , iar dezvoltarea și utilizarea s ă trebuie privite din perspectiva cerin Ńelor mai largi ale
organiza Ńiei. Prin urmare, ciclul de via Ńă al unui sistem informa Ńional aferent unei organiza Ńii este
inerent legat de ciclul de via Ńă al sistemului de baze de date care îl sus Ńine, și de asemenea, ciclul de
viaŃă al aplica Ńiei de tip baz ă de date este inerent legat de ciclul de via Ńă al sistemului informa Ńional.

Ciclul de via Ńă al unui sistem informa Ńional implic ă existen Ńa mai multor faze:
/lozenge6 studiu de fezabilitate;
/lozenge6 analiza cerin Ńelor;
/lozenge6 proiectarea conceptual ă a datelor și opera Ńiilor;
/lozenge6 proiectarea logic ă;
/lozenge6 proiectarea extern ă;
/lozenge6 realizarea de prototipuri;
/lozenge6 proiectarea intern ă și implementarea;
/lozenge6 testarea și validarea;
/lozenge6 între Ńinerea (mentenan Ńa);
iar etapele principale ale ciclului de via Ńă ale unei aplica Ńii de tip baz ă de date sunt [Conn]:
/lozenge6 planificarea bazei de date;
/lozenge6 definirea sistemului;
/lozenge6 colectarea și analiza cerin Ńelor;
/lozenge6 proiectarea bazei de date ;
/lozenge6 alegerea sistemului SGBD (op Ńional);
/lozenge6 proiectarea aplica Ńiei;
/lozenge6 realizarea prototipului (op Ńional);
/lozenge6 implementarea;
/lozenge6 conversia și implementarea datelor;
/lozenge6 între Ńinerea opera Ńional ă.

Proiectarea sistemelor informatice de gestiune
Metode de proiectare a bazelor de date E 85 Etapa de proiectare a bazei de date reprezint ă procesul de realizare a unui proiect pentru o baz ă de
date, care va trata toate opera Ńiile și obiectivele organiza Ńiei. Calitatea unei aplica Ńii de baze de date
depinde de proiectarea sa.

Scopurile etapei de proiectare a bazei de date sunt:
/lozenge6 reprezentarea datelor și a rela Ńiilor dintre ele, necesare tuturor domeniilor de ap lica Ńie și
grupurilor de utilizatori principali;
/lozenge6 furnizarea unui model de date care s ă accepte efectuarea oric ărei tranzac Ńii necesare asupra
datelor;
/lozenge6 specificarea unui proiect minimal, structurat în mo d adecvat pentru realizarea cerin Ńelor stabilite
privind performan Ńele sistemului, cum ar fi timpul de r ăspuns.
În proiectarea unui sistem de baze de date se pot u tiliza mai multe strategii de abordare dintre care
cele mai cunoscute sunt:
/lozenge6 Proiectare de jos în sus ( bottomîup sau ascendentă ), care începe prin definirea atributelor, a
asocia Ńiilor dintre atribute, și în final gruparea acestora în entit ăŃi. Un astfel de tip de abordare
este reprezentat de procesul de normalizare . Normalizarea implic ă identificarea atributelor
necesare și plasarea lor în tabele normalizate, bazate pe dep enden Ńele func Ńionale dintre atribute.
Acest tip de proiectare a unui sistem de baze de da te este indicat în proiectarea unor baze de date
simple, cu un num ăr relativ mic de atribute.
/lozenge6 Proiectare de sus în jos ( topîdown sau descendentă ), este indicat ă în proiectarea unor
aplica Ńii de tip baze de date complexe. Aceasta începe cu realizarea unor modele de date, care
con Ńin câteva entit ăŃi și rela Ńii de nivel înalt, dup ă care se aplic ă rafin ări succesive de sus în jos,
pentru a identifica entit ăŃile, rela Ńiile și atributele asociate de nivel jos. Acest tip de ab ordarea este
specific modelului Entitate – Rela Ńie , care începe cu identificarea entit ăŃilor și rela Ńiilor dintre ele
care prezint ă interes pentru organiza Ńie.
De asemenea, toate metodologiile utilizate în etapa de proiectare (numit ă și etapa de modelare) a
bazelor de date cuprind trei etape principale, și anume:
/lozenge6 Proiectarea conceptuală (elaborarea modelului conceptual) – reprezint ă procesul de construire a
unui model al informa Ńiilor utilizate în cadrul unei organiza Ńii, independent de toate considera Ńiile
fizice. Această faz ă este complet independent ă de detaliile de implementare (elementele software
ale SGBD-ului, programe de aplica Ńii, limbaje de programare, platforma hardware, etc. ).
/lozenge6 Proiectarea logică (elaborarea modelului logic) – reprezint ă procesul de construire a unui model
al informa Ńiilor utilizate în cadrul unei organiza Ńii, bazat pe un anumit model de date, dar
independent de un anumit SGBD și de alte considera Ńii fizice.
/lozenge6 Proiectarea fizică (elaborarea modelului fizic) – reprezint ă procesul de realizare a unei descrieri
a implement ării bazei de date într-o capacitate de stocare secu ndar ă; descrie structurile de stocare
și metodele de acces utilizate pentru realizarea unu i acces eficient la date. Modelul rezultat în
urma acestei etape este cel care st ă la baza materializ ării bazei de date propriu-zise.
Proiectarea bazei de date se poate realiza în dou ă moduri:
/lozenge6 pornind de la o baz ă de date existent ă, utilizând procedeul reverse engineering (proiectare
invers ă);
/lozenge6 pornind de la zero, elaborând pe rând cele trei mod ele enumerate mai sus utilizând procedeul
forward engineering (proiectare direct ă).
Când un administrator de baze de date este întrebat ce instrument CASE ( Computer Aided Software
Engineering ) folose ște în proiectarea, implementarea și analiza bazelor de date, unii vor r ăspunde
Oracle Designer, al Ńii CA ERWin/ERX sau Embarcadero ERStudio, iar al Ńii vor opta pentru Rational
Rose și lista poate continua. Desigur, op Ńiunile de alegere a unui anumit instrument sunt dic tate, în
general, de preferin Ńe de natur ă subiectiv ă – cunoa șterea respectivului instrument fiind decisiv ă în
alegerea produsului.

Proiectarea sistemelor informatice de gestiune
Metode de proiectare a bazelor de date E 86 6.1. Proiectarea bazelor de date
utilizând regulile de business
Una din metodele propuse de Microsoft pentru proiec tarea conceptual ă a unei baze de date este ORM
(Object Role Modeling ). În Microsoft® Visio® for Enterprise Architects se poate utiliza o diagram ă
de tip ORM pentru a elabora modelul conceptual al u nei baze de date. Modelul rezultat este
independent de platforma pe care se va implementa b aza de date rezultat ă.

Dar ce reprezint ă ORM ?

ORM reprezint ă o descriere general ă a bazei de date, utilizând simboluri intuitive pen tru obiecte și
atribute și care verbalizeaz ă (exprim ă) rela Ńiile dintre acestea, utilizând o gam ă larg ă de constrângeri
care surprinde și for Ńeaz ă regulile de afaceri.

De asemenea, ORM este un mod de abordare conceptual de un nivel înalt, utilizat pentru modelarea
datelor care descrie domeniul aplica Ńiei (lumea este v ăzut ă în termeni ai obiectelor, și a rolurilor pe
care aceste obiecte le îndeplinesc) utilizând în ac est scop simboluri intuitive și un limbaj natural pe
care atât utilizatorii cât și proiectan Ńii bazei de date le poate în Ńelege. Fiecare tip de element al faptului
care are loc între tipuri de obiecte este verbaliza t și afi șat într-o diagram ă de schem ă conceptual ă. În
acela și timp, ORM permite folosirea unui set extins de co nstrângeri pentru a surprinde regulile de
afaceri ( business rules ), precum și încorporarea unor exemple pentru verificarea proi ectului.

Procedura de proiectare a schemei conceptuale ORM s e caracterizeaz ă prin analiza și proiectarea
datelor. Schema conceptual ă specific ă structura informa Ńional ă a aplica Ńiei prin intermediul tipurilor
de fapte . Un model surs ă ORM poate fi folosit în loc de, sau înaintea unui alt model de proiectarea a
bazei de date.

ORM permite:
/lozenge6 Proiectarea conceptual ă a bazei de date folosind fapte și exemple descrise într-un limbaj natural.
/lozenge6 Construirea automat ă a modelelor logice și fizice ale bazei de date pe baza faptelor exprima te
într-un limbaj natural.
/lozenge6 Modelul bazei de date este creat într-un limbaj car e poate fi în Ńeles de utilizatorii non-tehnici.
Dintre caracteristicile mai importante ORM enumer ăm:
/lozenge6 este ușor de în Ńeles – exprim ă fapte și reguli în limba englez ă și / sau alte grafice intuitive;
/lozenge6 este fiabil – valideaz ă regulile folosind limba englez ă și mostre de date;
/lozenge6 este expresiv – surprinde în mod grafic multe reguli de business și mai complexe;
/lozenge6 este stabil – minimizeaz ă impactul modific ărilor asupra modelului și interog ărilor.

Proiectarea sistemelor informatice de gestiune
Bibliografie E 87 BIBLIOGRAFIE
[Andronie, 2007] Andronie M., Analiza și proiectarea sistemelor informatice de gestiune ,
Editura Funda Ției Române de Mâine, Bucure Țti, 2007
[Bocu, 2002] Bocu D., Ini țiere în modelarea obiect orientat ă a sistemelor utilizând UML ,
Grupul microINFORMATICA, Cluj-Napoca, 2002
[Bodur&alt, 1982] Bodur-L ăŃescu Gh., Ciobanu Gh., B ăncil ă I., Analiza drumului critic ,
Editura Știin Ńific ă și Enciclopedic ă, Bucure ști, 1982
[Bosksenbaum, 2002] Boksenbaum L., Informatic ă de gestiune , Editura Economic ă, Bucure Țti,
2002
[Davidescu, 1998] Davidescu N.D., Sisteme informatice financiar-bancare. Concepte
fundamentale. Modelare prin metoda MERISE , vol. I, Editura ALL BECK,
Bucure ști, 1998
[Davidescu, 1999] Davidescu N.D., Sisteme Informatice financiar-bancare – Metoda Meri se ,
Vol II Aplica Ńii Practice, Editura ALL Beck, Bucure ști,1999
[Georgescu, 2002] Georgescu C., Abordarea rela Ńional ă și obiectual ă în analiza sistemelor
informatice , Editura Didactic ă și Pedagocic ă, Bucure ști 2002
[Lungu1&alt, 1995] Lungu I., Bodea C., B ădescu G., Ioni Ńă C., Baze de date. Organizare,
proiectare și implementare , Editura All Educational, Bucure ști, 1995
[Lungu&alt, 1995] Lungu I., Sab ău Gh., Bodea C., Surcel Tr., Sisteme informatice pentru
conducere , Editura Siaj, Bucure ști, 1995
[Lungu&alt, 2003] Lungu I., Sabau Gh., Velicanu M., Muntean M., Ionescu S., Posdarie E.,
Sandu D., Sisteme informatice. Analiz ă, proiectare și implementare , Editura
Economic ă, Bucure ști, 2003
[Meyer, 1997] Meyer B., Object – Oriented Software Construction , Second Edition,
Prentice Hall, 1997
[Nistor&alt, 2003] Nistor R., Nistor C., C ăpăŃân ă Al., Metodologii manageriale informatice ,
Editura Academica, Gala Ńi, 2003
[Oprea, 1999] Oprea D., Analiza și proiectarea sistemelor informa Ńionale economice ,
Editura Policrom, Ia și, 1999
[Ro Țca&alt, 1993] Ro șca I., Macovei E., Davidescu M., R ăileanu V., Proiectarea sistemelor
informatice financiar-contabile , Editura Didactic ă și Pedagogic ă, Bucure ști,
1993
[V ătui, 2000] V ătui M., Metode de analiz ă orientat ă obiect a sistemelor informa Ńionale –
Tez ă de doctorat, A.S.E. Bucure ști, 2000
[Vîrlan, 2001] Vîrlan G., Utilizarea limbajului de modelare UML în analiza ți proiectarea
sistemelor , Editura Mongabit, Gala Ți, 2001
[Vîrlan, 2004] Vîrlan G., Tehnologii client/server în dezvoltarea sistemelor informatice în
economie , Editura Didactic ă și Pedagogic ă R.A., Bucure ști, 2004