Managementul Şi Proiectarea Sistemelor Informatice de Gestiune

CONSTANTIN AVORNICULUI MIHAI AVORNICULUI
MANAGEMENTUL ŞI PROIECTAREA
SISTEMELOR INFORMATICE DE
GESTIUNE
EDITURA RISOPRINT
CLUJ-NAPOCA, 2010
Coordonator:
Prof. Univ. Dr. Constantin AVORNICULUI
ContribuŃia autorilor:
Prof. Univ. Dr. Constantin AVORNICULUI (Capitolele: 1, 2, 4, 6, 7)
Lect. Univ. Dr. Mihai AVORNICULUI (Capitolele: 3, 5, 7)
Introducere
PerfecŃionarea continuă a activităŃii economice, impune utilizarea pe scară tot mai

largă a celor mai noi realizări ale informaticii, deci dezvoltarea şi diversificarea diverselor
sisteme, în mod deosebit a celor informatice economice şi sistemelor de operarea aferenta
acestora. Acest lucru duce la un proces continuu de extindere şi îmbunătăŃire a sistemelor în
general şi în mod special a celor informatice economice, la toate nivelurile organizatorice ale
economiei naŃionale.
Informatica poate fi definită ca o activitate pluridisciplinară orientată spre
proiectarea şi exploatarea sistemelor de prelucrare a informaŃiilor, în scopul eficientizării şi
rentabilizării activităŃii umane. După dicŃionarul explicativ DEX, informatica este ştiinŃa
care se ocupă cu studiul prelucrării informaŃiei cu ajutorul calculatoarelor.
Informatica managerială vizează informatizarea activităŃii manageriale şi mai exact a
managementului firmei. Informatica managerială se aplică pe sistemul informaŃional al
firmei.
Sistemul informaŃional este un ansamblu tehnico-organizatoric de proceduri de
constatare, consemnare, culegere, verificare, transmitere, stocare şi prelucrare a datelor, în
scopul satisfacerii cerinŃelor informaŃionale necesare conducerii procesului fundamentării şi
elaborării deciziilor. Aceste proceduri fac legătura între diferiŃi actori de (exemplu un client
şi salariatul de la ghişeul unei bănci), documentele pe care aceştia le elaborează sau în baza
cărora acŃionează (de exemplu contractul de creditare sau de depozit), forma sub care
documentele (datele incluse în ele) sunt stocate în calculator sau de suporŃi externi,
documentele care consemnează efectuarea unor operaŃii (de exemplu chitanŃe sau facturi) şi
diferite rapoarte sau liste de sinteză cum ar fi extrasul de cont situaŃia penalizărilor pentru
întârzieri în plata datoriilor, etc. Partea informatizată din sistemul informaŃional devine
sistem informatic.
Sistemul informatic constă din partea automatizată a sistemului informaŃional
(utilizatorii implicaŃi în automatizare şi cadrul organizatoric aferent) căreia i se adaugă şi
alte elemente necesare pentru automatizarea obŃinerii informaŃiilor necesare conducerii în
procesul de fundamentare şi elaborare a deciziilor şi anume: echipamente (hardware),
programe (software), comunicaŃii, o bază ştiinŃifică şi metodologică precum şi baza
informaŃională.
Baza ştiinŃifică şi metodologică constă din modele matematice ale proceselor şi
fenomenelor economice, metode şi tehnici de realizare a sistemelor informatice.
Baza informaŃională se referă la datele supuse prelucrării, fluxurile informaŃionale,
sistemele şi nomenclatoarele de coduri. Odată cu dezvoltarea cercetării operaŃionale, a
teoriei deciziei, a Internetului şi a performanŃelor calculatoarelor, au apărut sisteme
informatice dedicate cum ar fi sistemele suport de decizie şi sistemele expert, dar şi unele
sisteme informatice de tip nou ca cele pentru proiectare asistată de calculator, sistemele
multimedia, sistemele pentru comerŃul electronic şi sistemele deschise.
Sistemele suport de decizie sunt colaboratori ai decidentului, în timp ce sistemele
expert sunt sisteme de inteligenŃă artificială şi se comportă ca un expert, adică rezolvă o
mare parte din procesul elaborării deciziilor, dar bineînŃeles sunt avute în vedere numai
deciziile referitoare la problemele pentru care sistemul expert a fost conceput.
În cadrul unei firmei tradiŃionale se folosesc:
• sisteme de prelucrare a tranzacŃiilor (la nivel tranzacŃii)
• sisteme pentru conducerea operativă (la nivel operaŃional)
• sisteme de sprijinire a deciziilor – Decision Suport Systems (DSS) (la nivel tactic)
4
• sisteme pentru conducere (la nivel strategic)
În condiŃiile apariŃiei şi dezvoltării inteligenŃei artificiale precum şi a paradigmei
modelării cu ajutorul obiectelor au apărut sistemele expert şi sistemele pentru conducerea
executivă. Spre deosebire de sistemele pentru conducere, care fac analiza informaŃiilor,
generează rapoarte şi rezolvă probleme structurate, sistemele pentru
conducerea executivă permit evaluarea situaŃiei în analize oportune, la nivelul conducerii
de vârf, într-o manieră inteligentă.
Pe de altă parte, amploarea pe care a luat-o Internetul a dus la posibilitatea lucrului
în grupuri ale căror membri se află la distanŃă unii faŃă de alŃii, ceea ce s-a materializat prin
apariŃia grupurilor de lucru, iar în informatică prin apariŃia sistemelor pentru grupuri de
lucru. Toate sistemele enumerate mai sus, la nivelul la care operează, asigură
atingerea a două obiective:
• sprijinirea procesului informational, respectiv asigurarea suportului pentru
culegerea, filtrarea şi vehicularea datelor ce caracterizează activitatea firmei
sau organizaŃiei
• sprijinirea procesului decizional, care se referă la furnizarea informaŃiilor
necesare luării deciziilor în probleme semistructurate sau nestructurate
ApariŃia grupurilor şi ulterior a organizaŃiilor care presupun colaborare între
firmelor sau instituŃii face necesară fixarea unui al treilea obiectiv care Ńine de sprijinul
sistemelor de decizii pentru a-şi putea îndeplini obiectivul lor în condiŃiile dispersării
teritoriale.
Este vorba de sprijinirea procesului de comunicaŃie, prin care informaŃiile sunt
vehiculate între diferite categorii de utilizatori sau de utilizarea simultană a informaŃiilor de
către mai mulŃi utilizatori. Pentru aceasta sistemelor informatice de mai sus, li s-au alăturat
sistemele de sprijinire a conducerii executive, sistemele suport pentru decizii de grup şi
sistemele de sprijinire a deciziilor la nivel organizaŃional.
Ele reprezintă infrastructura pentru sistemele pentru a căror sprijin au fost concepute.
Scopul acestei discipline este de a familiariza studenŃii cu aceste categorii de sisteme
informatice folosite în managementul firmelor moderne, cărora li se mai pot
alătura şi alte sisteme, cum ar fi sistemele informatice organizaŃionale inteligente.
Acestea din urmă satisfac cerinŃele organizaŃiei pe scară mare, prin:
• sprijinirea activităŃilor paralele
• asistenŃă inteligentă în comunicaŃiile de grup, negocieri şi conflicte
• facilităŃi de procesare distribuită
• tehnici de planificare multiparticipant
• facilităŃi de învăŃare
Realizarea unui sistem informatic cu baze de date constituie o activitate complexă,
care presupune îmbinarea strânsă a cunoştinŃelor economice cu cele privind teoria
sistemelor, structurarea datelor, programarea şi utilizarea calculatoarelor.
Această carte se doreşte a se adresa studenŃilor ce studiază disciplina de
Managementul şi proiectarea sistemelor informatice, se mai adresează şi altor categorii de
specialişti ce lucrează în domeniul proiectării sistemelor informatice şi nu numai acestora.
Dorim să credem că această carte aduce unele completări în privinŃa problemelor teoretice şi
practice de elaborare a proiectelor informatice şi în alte privinŃe privind sistemele
informatice.
Lucrarea are menirea să asigure însuşirea cunoştinŃelor de specialitate în domeniul
analizei, conceperii, realizării, implementării şi utilizării sistemelor informatice cu baze de
date la un agent economic sau o firmă.
5
Am urmărit integrarea unor concepte, metode şi tehnici moderne de proiectare a
diverselor tipuri de baze de date, într-o metodologie unitară care să răspundă cerinŃelor
actualilor şi viitorilor specialişti, considerăm că lucrarea răspunde stadiului actual de
dezvoltare ale economiei noastre naŃionale.
Cartea este concepută să prezinte în mod logic principiile, metodele şi tehnicile
necesare unei proiectări cât mai logice a unei baze de date în domeniul economic şi în alte
domenii.
În acest scop au fost alese două moduri de proiectare a bazelor de date, unul pentru
cele clasice şi altul pentru noile tipuri de apărute, pe care le-am numit neoclasice.
Prezenta carte este structurată pe şapte capitole al cărui conŃinut sintetic îl prezentăm
în continuare.
În capitolul 1 sunt prezentate noŃiuni despre teoria sistemelor şi managementul lor.
Capitolul 2 prezintă necesităŃi şi modul de găsire a unor proiecte de informatică.
Capitolul 3 prezintă analiza sistemelor sub diverse aspecte.
Capitolul 4 prezintă proiectarea şi specificaŃiile acesteia.
Capitolul 5 prezintă elemente ale modelării orientate pe obiect cu prezentarea
metodelor necesare acestora.
Capitolul 6 prezintă testarea, implementarea şi exploatarea sistemelor informatice.
Capitolul 7 prezintă eficienŃa sistemelor informatice.
Lucrarea încearcă să prezinte metode şi tehnici de elaborare a modelului conceptual
al viitorului sistem informatic pe bază de criterii funcŃionale, prin stabilirea conŃinutului şi
structurii bazei informaŃionale, cu tehnica de modelare entitate-atribut-corespondenŃă şi
diagramele entitate-relaŃie.
Transformarea modelului conceptual în model operaŃional este asigurată de
proiectarea de detaliu sau tehnică. Acest obiectiv impune alegerea soluŃiei optime de gestiune
a datelor şi a calculatorului, ce sunt prezentate pe parcursul acestei cărŃi, în capitolele
aferente.
Cartea se vrea a fi un bun ghid studenŃilor ce elaborează lucrări de diplomă în
domeniul proiectării de aplicaŃii informatice economice, precum şi specialiştilor ce doresc să
elaboreze diverse sisteme informatice.
Autorii mulŃumesc cu anticipaŃie cititorilor ce vin cu sugestii de îmbunătăŃire a
conŃinutului şi formei de prezentare.
Autorii
6
Cuprins
NoŃiuni de bază ale sistemelor.......................................................................... 13

1.1. Sisteme, sistemul informaŃional şi abordarea sistemică ............................................... 13
1.1.1. Teoria sistemelor ................................................................................................................ 13
1.1.2. Feluri de sisteme................................................................................................................. 14
1.1.3. Abordarea cibernetică a sistemelor..................................................................................... 14
1.1.4. Principiul de integrare ........................................................................................................ 15
1.1.5. Feluri de integrări ............................................................................................................... 15
1.1.6. Reglarea prin integrare ....................................................................................................... 16
1.1.7. Sisteme integrate şi grade de integrare ............................................................................... 16
1.1.8. Sisteme hiperintegrate ........................................................................................................ 17
1.2. Sistemul informaŃional: concept şi structură ................................................................ 18
1.2.1. Sistemul informaŃional ....................................................................................................... 18
1.3. Sisteme informaŃionale economice, datele şi informaŃiile............................................ 21
1.3.1. EvoluŃia sistemelor informaŃionale..................................................................................... 22
1.3.2. Felurile sistemelor informaŃionale...................................................................................... 22
1.3.3. Ciclul prelucrării datelor..................................................................................................... 23
1.3.4. Componentele sistemelor economice ................................................................................. 25
1.3.5. Sisteme economice integrate .............................................................................................. 27
1.4. Fluxul informaŃional ..................................................................................................... 27
1.5. Circuitul informaŃional ................................................................................................. 28
1.6. FuncŃiile sistemului informaŃional................................................................................ 28
1.7. PerfecŃionarea sistemelor informaŃionale ..................................................................... 29
1.8. Sistemul informatic ...................................................................................................... 29
1.8.1. Sisteme informatice de gestiune (SIG) ............................................................................... 31
1.8.2. Tipuri de sisteme informatice ............................................................................................. 32
1.8.3. Ciclul de viaŃă al unui sistem informatic ............................................................................ 44
1.8.4. Rolul sistemelor informatice în conducerea organizaŃiilor economice............................... 46
1.9. EvoluŃia metodelor de abordare a sistemelor informaŃionale....................................... 46
1.9.1. Caracteristicile metodelor de abordare a sistemelor ........................................................... 47
1.9.2. Metoda descompunerii funcŃionale..................................................................................... 47
1.9.3. Metoda fluxurilor de date ................................................................................................... 48
1.9.4. Metoda orientată spre informaŃii ........................................................................................ 48
1.9.5. Metoda orientată pe obiect.................................................................................................. 48
1.10. Managementul proiectelor informatice ...................................................................... 49
1.10.1. Aspecte definitorii şi organizatorice................................................................................. 49
1.10.2. Metodologii de management ale proiectării ..................................................................... 51
1.10.2.1. Managementul afacerii şi tehnologia informaŃiei .......................................................... 51
1.10.3. Organizarea echipelor de analiză şi proiectare a activităŃilor ........................................... 56
1.10.4. Elaborarea specificaŃiilor de proiectare ............................................................................ 59
1.11. Principiile proiectării sistemelor informatice ............................................................. 60
1.12. Întrebări recapitulative ale capitolului........................................................................ 61
NecesităŃi ............................................................................................................ 63
2.1. Găsirea unor proiecte de dezvoltare ............................................................................. 63
2.2. Ierarhizarea proiectelor................................................................................................. 64
7
2.3. Alegerea proiectelor ..................................................................................................... 64
2.4. Organizarea şi planificarea sistemului.......................................................................... 65
2.4.1. Planificarea sistemelor........................................................................................................ 65
2.5. IniŃierea proiectului....................................................................................................... 67
2.6. Planificarea proiectului................................................................................................. 68
2.7. Analiza de fezabilitate .................................................................................................. 68
2.7.1. Felurile analizei de fezabilitate........................................................................................... 69
2.7.2. Stabilirea costurilor şi beneficiilor proiectului ................................................................... 69
2.8. Moduri de reprezentare a planurilor şi programelor calendaristice.............................. 70
2.9. Cuplarea........................................................................................................................ 71
2.9.1. Cuplarea elementelor.......................................................................................................... 71
2.9.2. Cuplarea obişnuită .............................................................................................................. 71
2.9.3. Cuplarea de control............................................................................................................. 71
2.9.4. Cuplarea matriŃelor ............................................................................................................. 72
2.9.5. Cuplarea datelor.................................................................................................................. 72
2.9.6. ImportanŃa cuplării ............................................................................................................. 72
2.10. Încapsularea datelor.................................................................................................... 72
2.10.1. Încapsularea datelor şi dezvoltarea produsului................................................................. 73
2.10.2. Încapsularea datelor şi menŃinerea produsului.................................................................. 73
2.11. Tipuri abstracte de date .............................................................................................. 73
2.12. Ascunderea informaŃiilor............................................................................................ 74
2.13. Obiecte........................................................................................................................ 74
2.14. Moştenire, polimorfism şi legare dinamică ................................................................ 74
2.15. Unitatea şi cuplarea obiectelor ................................................................................... 75
Analiza sistemelor.............................................................................................. 77
3.1. Scopul şi fazele de realizare a analizei ......................................................................... 77
3.1.1. Analiza – diagnostic informaŃională................................................................................... 77
3.1.2. Analiza celulară .................................................................................................................. 78
3.1.3. Tehnici de analiză ce pot fi utilizate şi în etapa de proiectare ............................................ 79
3.2. Modelarea logică şi diagramele fluxurilor de date ....................................................... 82
3.2.1. Tehnica Gane&Sarson........................................................................................................ 82
3.2.2. Tehnica Yourdon & DeMarco ............................................................................................ 86
3.3. DiferenŃele de modelare logică între cele două tehnici ................................................ 86
3.3.1. Modelarea sistemului curent............................................................................................... 87
3.3.2. RelaŃiile existente între DFD şi modelul datelor. ............................................................... 88
3.4. Feluri ale diagramelor fluxurilor de date...................................................................... 88
3.4.1. Diagrama de context........................................................................................................... 88
3.4.1. Diagrama fluxurilor de date fizice (DFDF) ........................................................................ 89
3.4.2. Diagrama fluxurilor de date logice (DFDL) ....................................................................... 89
3.4.3. Utilizarea DFD -lui în procesul de analiză ......................................................................... 90
3.5. Analiza orientată obiect (AOO).................................................................................... 91
3.6. Faza de organizare şi conducere a analizei sistemului existent.................................... 92
3.6.1. Pregătirea condiŃiilor necesare analizei sistemului existent ............................................... 92
3.6.2. Constituirea colectivului de analiză a sistemului existent .................................................. 93
3.6.3. Elaborarea planului de realizare a analizei ......................................................................... 93
3.7. Faza realizării analizei sistemului existent ................................................................... 93
3.7.1. Documentarea pentru analiza sistemului existent............................................................... 93
3.7.2. Alegerea procedeelor de analiză a sistemului existent ....................................................... 94
3.7.3. Studierea componentelor sistemului existent ..................................................................... 99
3.7.4. Metode de stabilirea cerinŃelor sistemului existent........................................................... 104
3.7.5. Evaluarea critică a actualului sistem................................................................................. 110
8
3.7.6. Evaluarea variantelor de proiectare şi realizare a sistemului informatic .......................... 113
3.8. Finalizarea analizei sistemului actual ......................................................................... 114
3.8.1. DocumentaŃia analizei sistemului actual .......................................................................... 114
3.8.2. Avizarea analizei actualului sistem .................................................................................. 115
Proiectare şi specificaŃii .................................................................................. 117
4.1. Etapele de bază ale proiectării şi structurarea sistemelor informatice........................ 119
4.1.1. Arhitectura sistemelor informatice ................................................................................... 121
4.1.2. Arhitectura sistemului informatic al unei firme................................................................ 122
4.2. Modele de proiectare a sistemelor .............................................................................. 123
4.2.1. Modelul în cascadă ........................................................................................................... 123
4.2.2. Modelul prototipului rapid................................................................................................ 125
4.2.2.1. Integrarea modelului cascadă şi a prototipului rapid ..................................................... 125
4.2.3. Modelul V......................................................................................................................... 125
4.2.4. Modelul W........................................................................................................................ 126
4.2.5. Modelul incrementat......................................................................................................... 127
4.2.6. Modelul spirală ................................................................................................................. 128
4.2.7. Modelul X......................................................................................................................... 129
4.2.8. Modelul pinball................................................................................................................. 130
4.2.9. Modelul fântână arteziană................................................................................................. 130
4.2.10. Modelul dezvoltării concurente (a mingii de baseball) .................................................. 131
4.2.11. Modelul piramidă ........................................................................................................... 132
4.3. Raportul dintre cerinŃele sistemului şi alegerea variantei optime de proiectare ................. 134
4.4. Modul de alegere al variantei optime şi tipuri de baze de date .................................. 135
4.4.1. Crearea variantelor strategice ale proiectului ................................................................... 135
4.4.2. Determinarea minimului necesar de informaŃii solicitate de noul sistem......................... 136
4.4.3. Tipuri de baze de date şi caracteristicile proiectării lor .................................................... 136
4.5. Planul de bază al proiectului....................................................................................... 137
4.6. Stabilirea obiectivelor sistemului informatic.............................................................. 138
4.7. ImportanŃa modelării datelor ...................................................................................... 140
4.7.1. Conceptul diagramă entitate-relaŃie.................................................................................. 141
4.8. Proiectarea situaŃiilor de ieşire ale sistemului informatic........................................... 144
4.9. Proiectarea bazei informaŃionale a noului sistem. ...................................................... 145
4.9.1. Stabilirea conŃinutului bazei informaŃionale..................................................................... 145
4.9.2. Algoritmi utilizaŃi de bazele informaŃionale..................................................................... 147
4.9.3. Stabilirea structurii bazei informaŃionale.......................................................................... 148
4.10. Formalizarea atributelor ........................................................................................... 153
4.10.1. Codificarea atributelor şi clasificarea lor........................................................................ 153
4.10.2. Coduri şi metode de verificare a acestora....................................................................... 155
4.10.3. Codificarea bazei informaŃionale.................................................................................... 158
4.10.4. Adaptarea documentelor folosite la cerinŃele noului sistem........................................... 160
4.11. Proiectarea structurală şi funcŃională a noului sistem informatic............................. 161
4.12. Modelarea conceptuală a datelor cu produsele CASE ............................................. 164
4.12.1. CASE şi principiile sale.................................................................................................. 166
4.12.2. Trăsăturile CASE-ului .................................................................................................... 168
4.13. Alegerea soluŃiei optime de gestiune a datelor şi a calculatorului ........................... 168
4.13.1. Metode de alegere a SGBD-urilor .................................................................................. 169
4.14. Etapele de realizare a bazelor de date....................................................................... 170
4.14.1. Analiza domeniului economic şi a cerinŃelor informaŃionale......................................... 171
4.14.2. Proiectarea structurii bazei de date ................................................................................. 171
4.14.3. Încărcarea datelor în baza de date................................................................................... 172
4.14.4. Exploatarea şi întreŃinerea bazei de date......................................................................... 172
4.15. Proiectarea orientată pe obiect (OOD) ..................................................................... 173
9
4.16. Tehnici formale pentru proiectarea detaliată ............................................................ 174
4.17. Tehnici de proiectare în timp real............................................................................. 174
4.18. Verificarea în timpul fazei de proiectare .................................................................. 175
4.19. Documentul de specificaŃii ....................................................................................... 176
4.20. ComparaŃia tehnicilor de specificaŃii........................................................................ 177
4.21. Instrumente CASE pentru faza de specificaŃii.......................................................... 178
4.22. Metrici pentru faza de specificaŃii ............................................................................ 178
4.23. Prototipizarea rapidă ca o tehnică de specificaŃie..................................................... 179
4.24. ImplicaŃiile manageriale ale modelului de prototip rapid......................................... 180
4.25. Întrebări recapitulative ale capitolului...................................................................... 182
Elemente ale proiectării orientate pe obiect ................................................. 183
5.1. Premisele orientării obiectuale ................................................................................... 183
5.2. Modelul orientat pe obiect.......................................................................................... 185
5.3. Modelarea use-case..................................................................................................... 185
5.4. Modelarea clasei ......................................................................................................... 185
5.4.1. Extragerea substantivului ................................................................................................. 186
5.5. Metodologia OMT (Object Modeling Tehnique)....................................................... 186
5.5.1. Concepte de bază .............................................................................................................. 186
5.5.2. Etape şi activităŃi .............................................................................................................. 188
5.5.3. ModalităŃi de reprezentare ................................................................................................ 191
5.6. Metodologia RUP (Rational Unified Process) ........................................................... 194
5.7. Metoda MDA (Model Driven Architecture) .............................................................. 199
5.7.1. CIM (Computation Independent Model) .......................................................................... 200
5.7.2. PIM (Platform Independent Model) ................................................................................. 200
5.7.3. PSM (Platform Specific Model) ....................................................................................... 200
5.7.4. Transformarea modelului ................................................................................................. 200
5.7.5. Tool-uri pentru MDA ....................................................................................................... 201
5.8. Metoda MDD (Model Driven Development)............................................................. 201
5.9. Limbajul UML (Unified Modeling Language) .......................................................... 203
5.9.1. ApariŃia şi evoluŃia limbajului .......................................................................................... 203
5.9.2. Definirea limbajului.......................................................................................................... 205
5.9.3. Concepte de bază .............................................................................................................. 207
5.9.4. Diagrame UML................................................................................................................. 211
5.10. Baze de date relaŃionale în context obiectual ........................................................... 244
5.10.1. Diagrama pentru modelarea datelor................................................................................ 244
5.10.2. Comportamentul tabelelor .............................................................................................. 245
5.10.3. Două orientări diferite .................................................................................................... 245
5.10.4. CorespondenŃa clasă-tabel .............................................................................................. 246
5.10.5. Asocieri între tabele........................................................................................................ 247
5.10.6. Obiecte persistente.......................................................................................................... 248
5.10.7. Modelarea şi proiectarea bazelor de date........................................................................ 252
5.10.8. Modelare business pentru proiectarea bazelor de date ................................................... 254
5.10.9. Realizarea unui baze de date pentru un magazin virtual ................................................ 256
5.11. Arhitectura sistemelor informatice ........................................................................... 262
Implementarea, exploatarea şi întreŃinerea sistemelor ............................... 267
6.1. Implementarea sistemului........................................................................................... 267
6.1.1. Planificarea implementării................................................................................................ 269
6.1.2. Realizarea şi testarea programelor.................................................................................... 270
6.1.3. SelecŃia CASE de test a modulelor................................................................................... 271
6.1.4. Tehnica „cutia neagră” de testare a modulelor ................................................................. 271
10
6.1.5. Testarea de echivalenŃă şi analiza valorilor de legătură ................................................... 272
6.1.6. Testare funcŃională ........................................................................................................... 272
6.1.7. Parcurgerea codurilor şi inspecŃiile .................................................................................. 273
6.1.8. ComparaŃia tehnicilor de testarea a modulelor ................................................................. 273
6.1.9. Camera goală (Cleanroom)............................................................................................... 273
6.1.10. Probleme potenŃiale în cazul testării obiectelor.............................................................. 274
6.1.11. Instalarea sistemului ....................................................................................................... 275
6.2. Documentarea sistemului ........................................................................................... 275
6.2.1. Întocmirea documentaŃiei ................................................................................................. 276
6.2.2. Instruirea utilizatorului ..................................................................................................... 277
6.2.3. Asistarea utilizatorilor ...................................................................................................... 278
6.2.4. Finalizarea proiectului ...................................................................................................... 279
6.3. ÎntreŃinerea şi exploatarea sistemului ......................................................................... 280
6.3.1. Aspecte ale întreŃinerii sistemelor .................................................................................... 280
6.3.2. Exploatarea curentă şi menŃinerea în funcŃionare a sistemului informatic ....................... 280
6.3.3. OperaŃiunii de întreŃinere a sistemului.............................................................................. 281
6.3.4. Reproiectarea proceselor economice ................................................................................ 281
6.4. Refolosirea modulelor ................................................................................................ 282
EficienŃa şi calitatea sistemelor informatice ................................................. 284
7.1. Teorii, concepte şi metode existente........................................................................... 284
7.2. Componente ale efectelor economice......................................................................... 289
7.3. Indicatorii tehnico-economici..................................................................................... 291
7.3.1. Indicatorul de satisfacere a cerinŃelor informaŃionale....................................................... 291
7.3.2. Indicatorul timpului de răspuns ........................................................................................ 292
7.3.3. Indicatorul eficienŃei economice....................................................................................... 293
7.3.4. Indicatorul duratei de recuperare ...................................................................................... 294
7.3.5. Indicatorul economiei de personal.................................................................................... 294
7.3.6. Indicatorul tehnico-economic ........................................................................................... 295
7.4. Evaluarea calităŃii ....................................................................................................... 295
11
1.
Capitolul
1 NoŃiuni de bază ale sistemelor
1.1. Sisteme, sistemul informaŃional şi abordarea sistemică

Deoarece universul este format dintr-o mulŃime de corpuri (obiecte şi fenomene
distincte), ce sunt într-o continuă mişcare, transformare, organizare şi reorganizare, deci
formează un sistem clasic.
Lumea este formată dintr-o infinitate de corpuri şi obiecte, care pare a fi discontinuă şi
neuniformă, de aceea pe lângă substanŃă şi energie a mai apărut aspectul de informaŃie.
Aceasta este după V.M. Gluşeav, expresia neuniformităŃii distribuŃiei substanŃei şi
energiei în timp şi spaŃiu, deoarece este ştiut că substanŃa reprezintă masa sau volumul,
energia reprezintă forŃa sau câmpul ce intervine în desfăşurarea fenomenelor. Deci, informaŃia
este modul în care sunt ele distribuite în timp şi spaŃiu [21].
1.1.1. Teoria sistemelor

Fiindcă toate corpurile, obiectele şi fenomenele sunt nişte sisteme, noŃiunea de sistem
nu se poate confunda cu fiecare în parte. Aceasta ne arată că obiectul respectiv este o unitate
complexă formată dintr-o mulŃime de elemente.
Ludowig Van Bertalanffy, este considerat părintele teoriei sistemelor, el defineşte
sistemul ca un ansamblu de elemente aflate în interacŃiune.
Sistemul este caracterizat nu numai prin relaŃiile dintre elemente, ci şi de relaŃiile
dintre părŃi şi întreg şi dintre întreg şi părŃi. Cu cât sistemul este mai puŃin organizat, cu atât
părŃile influenŃează sau controlează mai mult părŃile din care este format.
Sistemele sunt organizate pe mai multe niveluri, deoarece elementele lor sunt şi ele
formate din alte elemente, deci sunt subsisteme.
Orice subsistem de ordin superior este compus dintr-o mulŃime de subsisteme de ordin
inferior.
Procesul de supervizare, face ca subsistemul de ordin superior Să dobândească
proprietăŃi ce nu aparŃin subsistemelor componente, ci derivă din acŃiunea dintre acestea.
În accepŃiunea teoriei matematice a sistemelor, informaŃia este considerată expresie a
ordinei şi organizării, ce este specifică fiecărui subsistem în parte.
Putem demonstra că formula informaŃiei este identică cu formula entropiei
N
descoperită de L. Baltzmann, adică cu: H = −∑ p k log 2 p k (N >1), unde pk este
k =1
probabilitatea de realizare a unui eveniment k din sistem sau subsistem.
13
Managementul şi proiectarea sistemelor informatice de gestiune
O. Onicescu în 1979 arată că gradul de organizare a unui sistem poate fi măsurat cu

N
ajutorul energiei informaŃionale, astfel: E = ∑ p 2j ( A) , unde pj este probabilitatea de apariŃie a
j =1
evenimentului A.
InformaŃia, copie a revoluŃiei ştiinŃifice şi tehnice contemporane, se poate considera ca
o noŃiune foarte veche, înŃelegerea acesteia depinde de semnificaŃia ce i se poate atribui: ca
suport al cunoştinŃelor umane, ca biŃi şi alte unităŃi de măsură specifice informaticii [1].
Practica utilizează termenul de informaŃie şi pentru desemnarea datelor, deoarece,
pentru beneficiarul avizat, există o corespondenŃă determinată între informaŃie, simbol şi dată.
Sistemul dispune de operatori care acŃionează asupra intrărilor pentru a menŃine între
anumite limite stările şi ieşirile sale.
Teoria sistemelor arată că sistemele au următoarele principii: coordonabilitate,
incompatibilitate, optimalitate şi incertitudine.
Coordonabilitatea ne arată ca reglarea centralizată a unui sistem complex, dacă ea este
posibilă, nu este avantajoasă, datorită proceselor ce trebuie să fie reglate, a contradicŃiilor şi a
neliniarităŃii lor.
Incompatibilitatea, arată căci cu cât complexitatea sistemului este mai mare, cu atât
scade posibilitatea de a-l descrie în mod riguros.
Optimalitatea, arată că dacă un subsistem al uni sistem complex nu este optimal în
relaŃiile sale cu celelalte subsisteme, atunci nici sistemul complex nu mai este optimal.
Incertitudinea ne relevă că într-un sistem complex, starea unui subsistem şi
interacŃiunea sa cu celelalte subsisteme poate fi simultan determinată numai până la un anumit
grad de acurateŃe.
1.1.2. Feluri de sisteme

Fiindcă sistemele nu sunt identice intre ele, atunci diferitele sisteme se deosebesc între
ele.
Teoria sistemelor recunoaşte că după mulŃimea elementelor şi relaŃiile cu mediul, după
factorul timp, după coeficientul de complexitate şi după natura relaŃiilor dintre mărimile de
intrare şi cele de ieşire, sistemele pot să fie: finite sau infinite, închise sau deschise, statice
sau dinamice, simple sau complexe, determinate sau probabilistice, liniare sau neliniare, etc.,
această clasificare a fost făcută de Grunberg în 1977.
Teoria sistemelor permite distingerea sistemelor în funcŃie de complexitatea lor. Oricât
de independent ar fi un sistem, în realitate nu poate fi vorba decât de o independenŃă relativă,
fiindcă el este integrat împreună cu celelalte sisteme, cu care este în interacŃiune.
Fiecare sistem poate fi un subsistem şi fiecare subsistem poate face parte din mai
multe sisteme, devine necesară o abordare mult mai largă, deci una interdisciplinară.
Organizarea sistemelor duce la generarea altor sisteme care sunt din ce în ce mai
complicate şi mai diverse, diversitatea ne fiind provocată de substanŃă şi energia din care sunt
constituite, ci de modul cum sunt organizate. Deci, organizarea este cea care conduce la
diversitatea lumii în care trăim.
1.1.3. Abordarea cibernetică a sistemelor

Aprecierea sistemelor cibernetice este în direcŃia înlăturării factorilor perturbatori ce
acŃionează asupra sistemelor.
Autoreglarea, constă în existenŃa unei bucle de reacŃie, deci un mecanism de reglare în
circuit închis sau feed-back.
14
Sisteme, sistemul informaŃional şi abordarea sistemică
X Z Y
∆x
Deci, orice sistem are o intrare x, o ieşire y, comparată cu o funcŃie obiectiv z.

DiferenŃa ∆y, feed-back-ul, dintre funcŃia obiectiv z şi ieşirea propriu-zisă y acŃionează ca
element reglator asupra intrării x, deci noua intrare devine x + ∆y.
Există cazuri când nu se poate efectua o reglare eficientă prin feed-back, adică se
produc modificări ce nu se mai pot regla. În aceste cazuri, pentru păstrarea stabilităŃii
sistemului, este necesar mecanismul de prevedere a erorilor, prin care să aibă loc reglarea
dinainte a funcŃionării. Acest mecanism este numit feed-forward sau feed-frefare [21].
Această diferenŃă este clară, feed-back este realizat după ce are loc un fenomen sau un
proces, deci informare retroactivă, iar feed-frefare-ul apare pentru a preveni erorile din sistem,
deci are nevoie de informaŃii înainte de a avea loc fenomenul sau procesul interior.
Aceste mecanisme sunt într-o continuă intercondiŃionare, în vederea alegerii deciziilor
celor mai adecvate, feed-back-ul trebuie să Ńină seama de modificările din mediul extern şi de
cele interne, astfel încât centrul de comandă al feed-before-ului să devină şi centrul de
comandă al feed-back, de la care pleacă informaŃii spre organele de execuŃie, dar la care vin şi
informaŃii privind starea din fiecare moment a sistemului.
Mecanismele feed-back nu pot controla decât starea elementului reglat, deci acestea se
interpătrund, se etajează şi se supraetajează în sisteme tot mai puternic integrate, deci
hipersisteme [7].
Mecanismul feed-before lucrează probabilistic, deci apare factorul de risc, motiv
pentru care acesta se cuplează cu mecanismul feed-back, ce nu este probabilistic, pentru a se
corecta eventualele neconcordanŃe.
1.1.4. Principiul de integrare

Acesta derivă din principiul ordinii şi organizării, dacă diferitele elemente au tendinŃa
de a se organiza în sisteme, iar sistemele, la rândul lor, au tendinŃa de a se organiza în alte
sisteme din ce în ce mai complexe. Deci, pe lângă organizare, fenomenele tind şi spre o
integrare din ce în ce mai complexă.
Orice sistem este un subsistem al unui sistem mai mare, astfel: S1 < S2 < … < Sn.
Fiecare sistem (S1, … Sn) de la un anumit nivel de organizare, este format dintr-o
reuniune de subsisteme de ordin inferior, astfel: ∪ Si = S1 ∪ S2 … ∪ Sn.
Integrarea este necesară, deoarece unele subsistemele nu pot fi concepute în afara
sistemului.
1.1.5. Feluri de integrări

Integrarea genetică, care se bazează pe capacitatea sistemului, pe lângă ce de
organizare, să aibă şi pe cea de autogenerare. Deci, elementele sistemului fac parte din el,
deoarece au luat naştere în el însuşi.
Integrarea prin constrângere, poate fi întâlnită la toate nivelurile de organizare a
materiei, inclusiv la cele economice. Aceasta este o integrare prin forŃă, deci elementele
sistemului sunt obligate să funcŃioneze într-un anumit cadru.
Integrarea prin dependenŃă, se referă la elementele unui sistem care continuă să
rămână în cadrul lui, pentru că depind, într-un fel sau altul de alte elemente. Ea poate
15
interveni la toate nivelurile de organizare ale lumii materiale, precum şi la sistemele

economice.
Integrarea la alegerea, constă în posibilitatea elementelor de a alege sistemul căruia
să-i aparŃină. Aici elementele (subsistemele) au posibilitatea de a alege apartenenŃa la un
anumit sistem de organizare. Sistemul trebuie să desfăşoare o succesiune de procese
informaŃional-decizionale, având o mai mare libertate de acŃiune faŃă de integrările
precedente.
Integrarea la întâmplare, se referă la posibilitatea elementelor de a face parte dintr-un
sistem sau altul, pe baza unei întâmplări. Deci, cu cât un sistem este mai complicat, cu atât
întâmplarea joacă un rol mai mare, motiv pentru care trebuie să se apeleze la cercetarea
statistică.
1.1.6. Reglarea prin integrare

La sistemele cibernetice, reglarea reprezintă procesul prin care sistemele fac eforturi
pentru a-şi menŃine o anumită stare, nerealizată în mod spontan. În toate cazurile, procesele de
reglare, pe lângă elementul reglat, dispune de un regulator. Procesul de reglare presupune din
partea sistemului o anumită organizare şi oferirea codului propriu desfăşurării lui, lucru ce
înseamnă existenŃa substanŃei, energiei şi informaŃiei. Elementele sistemului pot fi organizate
în serie, paralel sau în circuit închis.
Organizarea în serie, dacă un element B al sistemului, ce urmează elementului A,
poate fi influenŃat de acesta, atunci elementul B poate fi reglat de elementul A.
Organizarea paralelă, oferă posibilitatea ca elementul A să poată înlocui sau
compensa o eventuală defecŃiune a elementului B.
Organizarea în circuit, constă în facilitatea ca un element B, care a fost influenŃat de
un element A, să influenŃeze la rândul lui elementul A, deci îl poate corecta.
Reglarea presupune cuplarea a cel puŃin două elemente, din care unul, asupra căruia se
exercită cele mai multe perturbaŃii, poate fi elementul reglat, iar celălalt reglator. La sistemele
complexe elementul reglator poate fi un adevărat element de reglare şi control. Cele mai noi
mijloace de reglare sunt: cuplarea şi înlănŃuirea elementelor, reŃelele, circuitele, redundanŃa,
substituirea, compensarea, dependenŃa şi constrângerea.
1.1.7. Sisteme integrate şi grade de integrare

Sisteme informatice integrate. NoŃiunea de sistem ca şi cea de subsistem sunt relative.
Orice sistem poate fi un subsistem al unui sistem de rang superior şi invers, orice subsistem,
atunci când face obiectul unui studiu detaliat, poate fi considerat un sistem. Conform
structurii sistemelor informatice, sistemul informatic al unei firmei (societăŃi comerciale)
poate avea câte un subsistem ataşat fiecărui domeniu de activitate. Ca urmare acolo vom avea
câte un sistem sau subsistem informatic pentru managementul financiar, contabil, comercial,
resurse umane, cercetare dezvoltare, etc.. Observăm că aceasta este o structurare a sistemului
pe orizontală. La rândul lor subsistemele pot fi divizate pe orizontală în aplicaŃii.
Astfel de exemplu în cadrul domeniului comercial vom avea aplicaŃiile [7] [21]:
• aprovizionare cu materii prime, produse şi materiale
• aprovizionare cu mărfuri de la furnizori
• contracte, livrare produse şi încasare facturi
• marketing
În cadrul fiecărui domeniu (subsistem) va avea loc şi o structurare pe verticală, în
sensul că subsistemul va furniza şi informaŃii sintetice pentru subsistemul de management
aflat la nivelul conducerii. De regulă aplicaŃiile se extind pe orizontală şi în alte domenii decât
16
Sisteme, sistemul informaŃional şi abordarea sistemică
în cel de care aparŃin oficial. Aşa de exemplu pentru a face statele de plată, biroul financiar
cere date de la resurse umane şi eventual de la producŃie, dacă salariul este plătit în acord.
Ca urmare între subsistemele informatice se prevăd prin program legături pe
orizontală sau uneori şi oblice. Un bun sistem informatic nu Ńine toate informaŃiile separat pe
subsisteme, ci deŃine şi informaŃii de uz în comun (shared). Uneori sistemele locale se leagă la
nivel de judeŃ sau naŃional (de minister).
Sistemele care deŃin legături între nivele dar şi între domenii se numesc sisteme
integrate. Dacă se combină structura pe orizontală cu cea pe verticală (prezentată în
introducere) sistemul local va arăta ca în figura de mai jos. În practică, firma trebuie să
dezvolte şi legături în exterior (cu băncile, cu piaŃa, cu concurenŃa (de ce nu?), cu ministerul
sau cu alte filiale din Ńară şi străinătate.
În sistemul integrat elementele trebuie să fie într-o strânsă interdependenŃă şi cu cât se
specializează mai mult în îndeplinirea unor funcŃii, dependenŃa lor devin tot mai mare. Pentru
sistemele complexe, sunt situaŃii în care apare ca necesară constituirea unor subsisteme
specializate, cu rol de realizare, coordonare şi integrare a tuturor elementelor într-un
subsistem.
Integrarea poate fi după rolul său, astfel [21]:
• prin subsisteme ce realizează integrarea structurală
• prin subsisteme ce realizează integrarea funcŃională
Integrarea structurală duce la relaŃii de vecinătate, dar sunt insuficiente, motiv pentru
care trebuie să colaboreze între ele.
Integrarea funcŃională se realizează în trei feluri, anume: substanŃială, energetică şi
informaŃională. Pe lângă relaŃiile de coordonare, între elementele sistemului apar şi relaŃii de
subordonare, deci trebuie să se supună problemelor integrării, sistemelor integrate.
Putem vorbi de o integrare orizontală, dar şi pe verticală, organizarea fiind pe niveluri
şi paliere. Nivelul cuprinde o mulŃime de sisteme autonome, între care nu sunt relaŃii de
subordonare. O mulŃime de niveluri de organizare formează un palier, situaŃie în care
integrarea realizându-se prin supervizare, palierele neavând formă de coloană, ci de piramide.
Cunoaştem că în funcŃie de sistem, gradul său de integrare este diferit.
1.1.8. Sisteme hiperintegrate

Pe lângă tendinŃa materiei de a se organiza în sisteme tot mai mari apare şi tendinŃa de
integrare. Cu cât creşte gradul de organizare, va scade gradul de integrare naturală şi creşte
integrarea prin dependenŃă.
1.1.8.1. Cauzele hiperintegrării

Generarea şi regenerarea elementelor, depind de celelalte elemente, deci se ajunge la
situaŃia totul depinde de totul. În acest caz apare o hiperintgrare prin dependenŃă a
elementelor sistemului.
Sistemele hiperintegrate au peste reŃelele care realizează legăturile substanŃial-energie
şi reŃelele specializate pentru realizarea legăturilor informaŃionale, deci formează o reŃea de
reŃele. Sistemele de integrare sunt reŃele ce coordonează şi mai ales subordonează pe celelalte,
deci totul se desfăşoară în favoarea sistemului.
În majoritate sistemelor, ele îşi păstrează identitatea prin intermediul mecanismelor de
reglare, ce le conferă hiperintegrarea.
1.1.8.2. Integratica
Integratica nu este o ştiinŃă universală, capabilă să realizeze orice problemă cu care
ne-am confruntat. Ea studiază legăturile indispensabile dintre diferite obiecte şi fenomene,
17
încercând să depăşească limitele extrem de rigide ale celorlalte ştiinŃe particulare, pe care nu
le poate înlocui, ne fiind de acord cu o abordare pe bucăŃi, ci promovează ideea unei viziuni
globale.
1.2. Sistemul informaŃional: concept şi structură

G. B. Davis a dezvoltat în mod veritabil cercetarea asupra conceperii sistemelor
informaŃionale automatizate pentru gestiunea firmei. Termenul de Sistem InformaŃional de
Gestiune (S.I.G) nu înglobează forŃat aspectul informatic, dar cea mai mare parte a lucrărilor
de cercetare îl foloseşte totuşi implicit sau explicit, referindu-se la computer-based
information system sau sistemul informaŃional automatizat [44].
Conceptul de sistem informaŃional şi structura sa este pe deplin justificat prin cel puŃin
argumente ca: acest concept a fost definit în funcŃie de specializarea autorilor şi de contextul
determinat de tipul lucrărilor elaborate; traducerea nu chiar exactă, a unor concepte din
literatura străină şi de introducerea de neologisme în limba română ce nu corespund
conŃinutului ce-l reprezintă; abordarea încă firavă a problematicii complexe referitoare la
proiectarea şi realizarea sistemelor informatice.
Complexitatea cercetării sistemelor informaŃionale a fost reliefată de J. L. Peaucelle,
astfel: “ În gestiune, informaŃia este omniprezentă. Fie că este vorba de ştiinŃele comerciale,
de gestiune a personalului, gestiunea productivă, de contabilitate sau finanŃe, gestionarul
colectează informaŃiile, le tratează şi le dă sens. A cerceta în gestiune înseamnă a propune noi
forme de informaŃii, noi maniere de a trata şi a le descoperi noi sensuri. “
V. Marinescu şi I. Faur dau următoarea definiŃie: “ sistemul informaŃional este un
ansamblu organizat şi integrat de date şi informaŃii, precum şi procedurile şi mijloacele pentru
colectarea, prelucrarea şi transmiterea acestora.”
Alquier şi Barthet definesc sistemul informaŃional astfel: “ansamblu de informaŃii
manipulate într-o firmă.”
Lemoigne defineşte sistemul informaŃional astfel: “un sistem de cuplaj între sistemul
operant şi sistemul de pilotaj.”
Sistemul informaŃional este un ansamblu organizat de resurse: materiale, de personal,
date, mijloace şi proceduri de culegere, memorare, prelucrare şi comunicare a informaŃiilor,
precum şi circuitele informaŃionale utilizate.
În acest sens, V. Stancovici în anul 1980, arată că orice sistem tinde să realizeze
maximum de organizare, concomitent cu o cât mai puternică integrare în sistemul superior.
1.2.1. Sistemul informaŃional

Activitatea de proiectare şi implementare a unor aplicaŃii informatice este în mod
esenŃial deductivă şi analitică, sprijinindu-se pe procese de descompunere foarte apreciate.
Utilitatea informaticii este apreciată în mod exclusiv după volumul datelor prelucrate
şi numărul aplicaŃiilor ce funcŃionează. FuncŃionarea acestor servicii informatice se realizează
în mod exclusiv în timp definit, iar exploatarea integrată este timidă, tehnica servind câteodată
ca pretext pentru limitele de deschidere a sistemelor.
Prin sistem se înŃelege ansamblul de elemente interdependente care interacŃionează
pentru atingerea unui scop.
Teoria sistemelor este utilă pentru a stabili modul de funcŃionare a firmei şi pentru a
înŃelege ce reprezintă pentru firmă tratarea informaŃiilor.
Un sistem este un ansamblu complex de componente distincte, identificabile, legate
între ele printr-un număr de relaŃii, componente ce sunt considerate subsisteme. Legăturile
18
Sistemul informaŃional: concept şi structură
între elementele componente condiŃionează funcŃionarea întregului sistem, funcŃionare care

mai este influenŃată şi de mediul din care face parte sistemul.
Un sistem se află într-un mediu şi dinamica îl menŃine, deci este activ şi evolutiv.
Deci, relaŃiile şi legăturile sistemului cu mediu sunt în ambele sensuri. De aceea unele stări
de dezechilibru pot fi identificate în cadrul acestui complex schimb de relaŃii în ambele
sensuri.
Conform teoriei generale a sistemelor, obiectivul unui sistem este întotdeauna ieşirea
sa. În majoritatea cazurilor scopul sistemului este prestabilit, legăturile şi funcŃiile sale fiind
cele care se adaptează scopului.
Dacă avem notaŃiile: XI = intrările sistemului, YI = ieşirile sistemului, atunci se poate
calcula transmutaŃia (T) sistemului, astfel: T = YI / XI
Teoria sistemelor propune o formulare a problemelor, dar tratează mai ales structuri şi
politici generale ale firmei, considerate ca un tot indisociabil.
Elementele interne fiind secundare pentru conducere, sistemul este reprezentat doar
prin contactul cu exteriorul şi relaŃiile sale cu acesta (intrări şi ieşiri). Variabilele de acŃiune
sunt intrările care pot fi manipulate de operatori. Variabilele esenŃiale sunt ieşirile care
informează asupra modului de funcŃionare a sistemului, conform figurii următoare [21]:
Mediu
Intrări Ieşiri
SISTEM
Variabile de acŃiune Variabile esenŃiale
Figura 1.1 FuncŃionarea sistemului [7]
Analiza sistemică permite modelarea conducerii unui sistem, conducere ce nu poate fi

făcută decât prin exteriorul sistemului, astfel:
• printr-un circuit dinamic care leagă intrările şi ieşirile prin intermediul unui
conducător extern
• receptorii sunt plasaŃi pe variabilele esenŃiale de ieşire şi informează
conducătorii asupra stării sistemului
• conducătorul compară ieşirile propuse cu ieşirile efective şi comandă
variabilele de acŃiune ale sistemului
O tipologie a sistemelor elaborată de economistul american K. Boulding, propune o
abordare pe nouă nivele [21]:
• primul nivel descrie un sistem pasiv, identificabil şi diferenŃiabil, iar
conŃinutul său poate fi cheia
• al doilea nivel descrie un sistem activ, prin care se învederează faptul că este
destinat să facă ceva
• al treilea nivel formalizează un sistem regulat, care dispune de o anumită
formă de regularitate în funcŃionarea sa
• al patrulea nivel defineşte un sistem informat, capabil să memoreze
informaŃiile şi să le utilizeze pentru a modifica comportamentul său
• al cincile nivel se referă la sistemul decizional, dotat nu numai cu o capacitate
de testare, dar capabil să interpreteze rezultatele prelucrării şi să decidă asupra
acŃiunii viitoare
• al şaselea nivel este sistemul memorizator, ce acŃionează şi elaborează
deciziile sale în funcŃie de informaŃiile pe care le stochează de-a lungul luării în
considerare şi tratării evenimentelor provenite din exterior
19
• al şaptelea nivel postulează faptul că sistemul coordonează deciziile de

acŃiune în funcŃie de situaŃiile care se prezintă ca nişte activităŃi diferenŃiate
• al optulea nivel este sistemul inteligent, ce dispune de o capacitate de
imaginaŃie şi elaborează noi forme de acŃiune, păstrează experienŃa trecută şi se
face înŃeles
• nivelul nouă arată faptul că este o consecinŃă prin care sistemul se
autofinalizează, apelându-se la factorul uman, singurul care poate transforma
finalităŃile sau identitatea
Se poate concluziona astfel [44]:
• orice sistem este un subsistem al unui sistem mai cuprinzător
• un sistem nu se poate găsi izolat, el funcŃionând întotdeauna într-un mediu
• descompunerea unui sistem în subsisteme se face pe diferite grade de detaliere,
iar agregarea, compunerea într-un sistem se face din subsistemele considerate
interconectate
• la un anumit grad de detaliere se poate vorbi despre un sistem sau un ansamblu
de elemente între care există anumite conexiuni
Un sistem se poate descompune în trei subsisteme diferite, astfel:
• subsistemul operaŃional sau condus, unde se desfăşoară fenomenele şi
procesele ce au rolul de a trata şi transforma nişte elemente
• subsistemul decizional sau de conducere, cu funcŃia de a coordona ansamblul
activităŃilor în funcŃie de obiectivul general şi de subobiectivele derivate
• subsistemul informaŃional sau de măsură, ce are rolul de a evidenŃia
desfăşurarea fenomenelor şi proceselor caracteristice subsistemului condus cât
şi al sistemului de conducere
Între cele trei subsisteme există conexiuni în ambele sensuri, trebuie remarcată însă şi
existenŃa unei conexiuni între cele trei subsisteme şi mediul exterior.
Sistemul informaŃional face legătura între sistemul de conducere şi sistemul condus
(operaŃional) şi este subordonat sistemului de conducere.
FuncŃionarea unui sistem informaŃional presupune următoarele activităŃi [21] [44]:
• culegerea datelor despre starea sistemului condus
• transmiterea datelor spre prelucrare
• prelucrarea datelor şi obŃinerea informaŃiilor necesare procesului decizional
• adoptarea deciziilor
• transmiterea deciziilor spre execuŃie
• asigurarea controlului şi realizarea deciziilor
Sistemul informaŃional include două tipuri de informaŃii:
• informaŃii pentru conducere
• fluxuri informaŃionale generale, ce reprezintă fluxurile fizice desfăşurate în
firmă
Alquier propune o tipologie care permite identificarea părŃii din sistemul
informaŃional ce poate fi automatizată, făcând legăturile cu tehnologiile şi metodele
informatice, astfel:
• sistem informaŃional individual – ce reprezintă suma sistemelor
informaŃionale ale fiecărui individ;
• sistemul informaŃional colectiv – ce regrupează informaŃiile care au un sens
global pentru firmă;
• sistemul informaŃional cooperativ – ce permite comunicarea între indivizi,
asigurând coordonarea între ei prin schimbul de informaŃii.
20
Sisteme informaŃionale economice, datele şi informaŃiile
Fiecare dintre ele corespunde unui tip de informatică şi unei concepŃii particulare care
permite realizarea unui mod concret de repartizare a mijloacelor de integrare.
APLICAłII INFORMATICE Sistemele de sprijinire a experŃilor

Sisteme de sprijinire a conducerii strategice
Sisteme de sprijinire a procesului decizional
Sisteme de informare a conducerii
Sisteme de prelucrare a tranzacŃiilor
Birotica şi sistemele grupurilor de lucru
ARHITECTURA SITEMELOR INFORMAłIONALE Date

Resurse umane
Echipamente
Software
ComunicaŃii
MEDIUL INTERN InformaŃii

Sisteme de funcŃii
Tot felul de resurse
Conducere
Structură organizatorică
MEDIUL EXTERN Furnizori

ClienŃi
ConcurenŃi
Bănci/Creditori
AcŃionari
Organisme guvernamentale
Figura 1.2 Componentele mediului de lucru a sistemelor [7] [21]
Problemele ridicate de proiectarea şi realizarea sistemelor, necesităŃile de coordonare

şi control a funcŃionalităŃii acestor sisteme, privilegiază abordarea sistemică şi analiza valorii
în activitatea de realizare a acestor obiective. Aceste teorii pun la dispoziŃie un mod de
gândire adaptat sistemelor evolutive şi complexe, care necesită luarea în considerare a unor
aspecte ca: considerarea oricărui obiect de studiu ca un sistem, reliefarea relaŃiilor între
componentele sale, favorizarea inovaŃiei, acceptarea ca logicele să fie atât contradictorii cât şi
complementare.
1.3. Sisteme informaŃionale economice, datele şi informaŃiile

Acesta este un ansamblu de resurse umane şi de capital, investite într-o unitate (firmă),
în vederea corelării şi prelucrării datelor necesare producerii informaŃiilor şi care se vor utiliza
la toate nivelurile decizionale şi controlul activităŃii unităŃii (firmei).
21
1.3.1. EvoluŃia sistemelor informaŃionale

În literatura de specialitate din ultima perioadă apar concepte ca: exclusiv information
system, ce trebuie să le dea de gândit traducătorilor, ce au tradus management information
system, sub formă de sistem informatic pentru conducere, deoarece şi această noŃiune are
aceeaşi semnificaŃie, dar ea se referă la vârful ei.
Se poate folosi în loc de management information system, expresia: management
reporting system, care se apropie de sistemele de raportare a gestiunii unei firme.
Primele noŃiuni apărute prin ani 70, sunt cunoscute ca sistem suport de decizie, putând
fi considerat ca un sistem de sprijinire a procesului decizional.
Anii 80 aduc noŃiunea de sistem expert, prin care se trece la prelucrarea cunoştinŃelor
umane.
Sistemele expert diferind de sistemele de automatizare a muncii de birou, cunoscute şi
sub numele de birotică, ce a apărut tot în anii 80.
Componentele mediului de lucru ale sistemelor informaŃionale sunt prezentate în
figură 1.2.
1.3.2. Felurile sistemelor informaŃionale

Deoarece sunt o diversitate de sisteme informaŃionale, considerăm ca necesară o
clasificare a lor după anumite criterii, dintre care prezentăm [22]:
a) După scopul urmărit de sistem, avem:
- de automatizare a activităŃilor de rutină
- de informare a conducerii
- de sprijinire a procesului decizional
- de sprijinire a grupurilor de lucru
- de sprijinire a procesului de comunicare
- de sprijinire a top-managerilor
b) După elementul supus analizei, avem:
- orientate spre funcŃii
- orientate spre procese
- orientate spre date
- orientate spre obiecte
- orientate spre mesaje şi comunicare
- orientate spre informaŃii ştiinŃifice
- orientate spre cunoştinŃe specializate
c) După modul de prelucrare al datelor, avem:
- de prelucrare manuală
- de prelucrare mecanografică
- de prelucrare automată
- de prelucrare mixtă
d) După modul de organizare al datelor, avem:
- bazate pe fişiere clasice
- bazate pe tehnica bazelor de date
- mixte
e) După gradul de centralizare, avem:
- centralizate
- descentralizate
f) După gradul de dispersie a resurselor sistemului, avem:
- locale, ce se împart:
○ sală calculator central
22
○ calculator unic
○ reŃea locală
- distribuite, ce pot fi:
○ prelucrarea a datelor distribuite
○ prelucrare distribuită a datelor
g) După utilizatorii activităŃii, avem:
- orientate pe utilizatori finali
- orientate spre factorii de decizie
- orientate spre utilizatori informatizaŃi
- orientate spre manageri informatizaŃi
h) După gradul de integrare, avem:
- neintegrate
- parŃial integrate
- total integrate
i) După felul calculatorului, avem:
- bazate pe calculatoare foarte mari
- bazate pe mini calculatoare
- bazate pe microcalculatoare
j) După gradul de automatizare a activităŃilor de analiză şi proiectare avem:
- dezvoltate pe proiectare clasică
- analizate cu instrumente automate şi proiectare clasică
- bazate pe instrumente diverse de automatizare a analizei şi proiectării
- dezvoltate cu instrumente de tipul CASE, dintre care:
○ CASE orizontal
○ CASE vertical
○ CASE integrat
○ OPEN CASE
○ EXPERT CASE
k) După felul relaŃiei pe care se bazează sistemul, avem:
- bazate pe reŃele LAN
- bazate pe reŃele MAN
- bazate pe reŃele WAN/IAN
1.3.3. Ciclul prelucrării datelor

El cuprinde cinci faze, anume: culegerea datelor, pregătirea datelor, prelucrarea
datelor, întreŃinerea fişierelor şi obŃinerea informaŃiilor de ieşire.
Faza de culegere a datelor are două activităŃi fundamentale şi anume:
• observarea mediului
• înregistrarea datelor
Pregătirea datelor are operaŃii ce se execută asupra datelor, anume:
• clasificarea datelor prin coduri
• gruparea datelor
• verificarea datelor
• sortarea datelor
• cuplarea
• transmiterea datelor
• transcrierea datelor
Prelucrarea datelor se referă la activităŃile:
• calculaŃie
23
• comparare
• sintetizarea
• filtrarea
• restaurarea
ÎntreŃinerea fişierelor, cu activităŃile:
• memorarea
• actualizarea
• indexarea
• protecŃia datelor
Datele sunt simboluri care caracterizează starea la un moment dat a unui fenomen,
proces sau poate defini un obiect, fiind percepute de oameni sau echipamente în vederea
prelucrării şi transformării lor în informaŃii.
Simbolurile foarte mult utilizate sunt sub formă de cifre, imagini, grafice, etc., este
necesar ca în activitatea de observare a lumii reale şi de reflectare a ei prin simboluri să
efectuăm operaŃii ca:
• denumirea acestora
• clasamentul sau măsurarea ordinală a acestora
• măsurarea cardinală prin valori
Pentru a deveni informaŃii datele trebuie prelucrate în concordanŃă cu cerinŃele
informaŃionale. Obiectivul prelucrării datelor constă în convertire datelor în informaŃii ce stau
la baza luării deciziilor.
Există diferenŃe între date şi informaŃii, anume:
• datele privesc evenimente primare colectate din diverse locuri, nedefinite şi /
sau neorganizate într-o formă care să stea la baza luării deciziilor
• informaŃiile sunt mesaje obŃinute prin prelucrarea datelor, mesaje ce trebuie să
fie concise, actuale, complete şi clare, astfel ca să răspundă cerinŃelor
informaŃionale în scopul cărora sunt prelucrate datele
Ca să devină informaŃii, datele trebuie să parcurgă următorul flux: introducerea lor,
prelucrarea şi extragerea rezultatelor.
Introducerea reprezintă procesul de culegere a datelor şi scrierea acestora într-o formă
accesibilă echipamentelor de calcul care vor efectua prelucrarea şi are patru etape, anume:
• culegerea datelor de la diverse surse;
• efectuarea verificării corectitudinii lor;
• codificarea datelor într-o formă accesibilă interpretării lor;
• transmiterea lor pentru efectuarea operaŃiilor solicitate de prelucrare
Prelucrarea datelor este făcută în urma introducerii şi se fac prelucrări ca:
• clasificarea în concordanŃă cu anumite caracteristici
• sortarea crescătoarea sau descrescătoare
• calcule aritmetice sau logice
• rezumarea datelor
• arhivarea selectivă a datelor şi rezultatelor prelucrărilor
Extragere informaŃiilor, în urma prelucrării şi are trei etape, anume:
• regăsirea rezultatelor din memorie
• conversii/decodificarea rezultatelor din forma în care sunt prelucrate, în formă
accesibilă utilizatorului
• transmiterea informaŃiilor la locul solicitat de utilizator
InformaŃiile obŃinute pot răspunde cerinŃelor pentru care au fost prelucrate datele sau
pot fi afectate de erori provenite din diversele etape ale prelucrării.
24
InformaŃia reprezintă datele transformate sub formă semnificativă pentru persoana

receptoare şi are o valoare reală pentru deciziile şi acŃiunile acesteia.
InformaŃia este un produs, rezultat al procesului de prelucrare al datelor, a analizei şi
interpretării rezultatelor, destinat satisfacerii informaŃionale a sistemului decizional.
Produs ce are următoarele caracteristici [21] [44]:
• informaŃia este umană
• noŃiune de informaŃie este relativă pentru destinatari
• informaŃia înmagazinată este o resursă reutilizabilă
• informaŃia este substituibilă
• informaŃia este comunicabilă
• informaŃia poate fi difuză
• valoare informaŃiei este legată de timp
• informaŃia se caracterizează prin probiguitate
• urmează regulile ciclului de viaŃă clasic a unui produs.
InformaŃia este cea mai importantă pentru performanŃa economică a firmei, din
considerente ca:
• că este un factor de producŃie
• că este un factor de sinergie
• este factor determinant al comportamentului indivizilor
• este sursă de decizii.
Martinet şi Ribault arată că informaŃia are o valoare dacă:
• contribuie la reducerea incertitudinii privind viitorul
• este susceptibilă la influenŃarea deciziilor adoptate
W.R. King are trei idei despre satisfacerile informaŃionale ale sistemului decizional,
anume:
• informaŃiile pe care noi le avem nu sunt acelea pe care noi le vrem
• informaŃiile pe care noi le vrem nu sunt acelea de care avem nevoie
• informaŃiile de care avem nevoie nu sunt disponibile
NoŃiunea de pertinenŃă este o interogare asupra valorii informaŃiei pentru utilizatorul
său. Valoare ce depinde de o mulŃime de caracteristici de reprezentare a utilităŃii.
PersistenŃa depinde de următorii factori [44]:
• precizia şi fineŃe
• exhaustivitate
• fiabilitate
• accesibilitate
• actualitate
• forme de reprezentare
1.3.4. Componentele sistemelor economice

Organismul asupra căruia se răsfrâng atribuŃiile sistemelor economice, pot să fie de
orice dimensiune, dar în cele mai multe cazuri, în literatura de specialitate, se înŃelege
economia unei Ńări.
InstituŃia este o formaŃie specială economică complexă, ca exemplu: o mare firmă sau
un minister.
Atunci, societatea trebuie privită ca şi materia în fizică. În acest caz molecula devine
instituŃia, iar în interiorul ei atomul este organizaŃia. Prezentăm în continuare atomii.
OrganizaŃia este o formaŃie constituită din oamenii unităŃii în vederea îndeplinirii
anumitor funcŃii social-economice determinate.
25
Unitatea reprezintă un element al sistemului economic ce nu se mai poate

descompune, comportându-se cu regularitate determinată şi răspunde conform unor reguli la
impulsurile primite.
Deosebirile dintre cele două sunt:
• organizaŃia este o formaŃie social reală, compunându-se din persoane vii, iar
sfera ei de activitate este stabilită juridic
• unitatea este o pură abstracŃie, având rol în modelarea activităŃilor desfăşurate
în cadrul organizaŃiei
FuncŃionarea sistemului constă în faptul că în fiecare perioadă primeşte un input şi
emite un output, modificându-şi în timp starea internă. Inputuri-le şi outputuri-le se numesc
fluxuri.
Procesul intern este acela ce are loc în interiorul unităŃii şi care transformă input-ul în
output, modificându-se şi starea internă a sistemului.
Starea unităŃii poate fi caracterizată de stocul din depozit, dar şi de informaŃiile
acumulate în birouri şi servicii.
UnităŃile fiind legate între ele prin fluxuri de input şi output, deci poate fi vorba de un
sistem. Procesele unui sistem economic sunt de două feluri: reale şi de reglare.
Procesele reale sunt procese materiale şi fizice, intrând: producŃia, circulaŃia şi
consumul, fiind notate cu R = real.
Procesele de reglare sunt procese intelectuale, aici intrând: observarea, transmiterea
informaŃiei, prelucrarea acesteia, pregătirea deciziei şi decizia.
Fiind descrise prin intermediul variabilelor de reglare şi sunt notate cu C = centru de
reglare.
În baza celor prezentate se poate vorbi de două subcategorii de procese, anume:
• procese reale interne, ca: producŃia şi consumul
• procese de reglare interne, ca: prelucrarea informaŃiei, pregătirea deciziei şi
decizia
Pe baza celor de mai sus, unităŃile economice (firmele) se pot încadra în două
categorii:
• unităŃi reale în care au loc exclusiv procesul real intern
• unităŃi de reglare în care au loc exclusiv procesul de reglare internă
Transformările ce au loc în sistemul economic şi ansamblul funcŃiilor de reacŃie ale
unităŃilor, legate între ele, sunt descrise prin două sisteme de funcŃii de reacŃie, anume:
• sisteme funcŃie de reacŃie a sferei de reglare
• sisteme funcŃie de reacŃie a sferei reale
Sistemul economic este compus din organizaŃii ce funcŃionează, respectiv din unităŃile
ce alcătuiesc aceste organizaŃii.
OrganizaŃiile sau unităŃile sunt legate între ele prin flux de produse şi de mesaje, iar
funcŃionarea sistemului economic este determinată de sistemul funcŃiilor de reacŃie.
MulŃimea organizaŃiilor, produselor şi tipurilor de mesaje, sistemul funcŃiilor de
reacŃie al sferei de reglare şi sistemul funcŃiilor de reacŃie al sferei reale reprezintă
caracteristicile sistemului economic.
Totalitatea caracteristicilor alcătuiesc structura sistemului.
Sistemul economic este un caz particular al teoriei matematice a sistemelor, deci,
putându-se aplica aceleaşi reguli.
Unitatea (firma) se poate privi ca un automat abstract complex integrat.
Mesajele sistemului economic pot să fie de trei feluri:
• purtătoare de informaŃii privind mişcarea bunurilor şi transmiterea cerinŃelor,
operaŃii de creditare, etc.
26
Fluxul informaŃional
• cu caracter de preŃ, ce arată valoarea numerică a variabilei mesajului cu

ajutorul unităŃilor de măsură băneşti
• fără caracter de preŃ, acelea care fac: descriere, tehnologice, acŃiuni economice,
etc…
UnităŃile (firmele) mari se pot clasifica activităŃile, astfel [1] [7]:
• conducători direcŃi ai producŃiei
• aparatul de cercetare şi dezvoltare al tehnicii
• conducătorii şi executorii investiŃiilor
• valorificare produselor unităŃii (firmei)
• aprovizionarea materialelor consumate
• personal specializat în alegerea resurselor umane
• personalul financiar-contabil.
1.3.5. Sisteme economice integrate

Integrat este un cuvânt cheie, el subliniază ideea că toate părŃile componente ale unui
sistem de prelucrare a datelor sunt intercorelate.
Managementul trebuie să considere unitatea (firma) ca pe un sistem complex format
din mai multe subsisteme strâns integrate. Aici informaŃiile fragmentate pot fi reŃinute, iar
apoi recuperate şi utilizate în diverse scopuri.
Sistemul integrat este acela în care activitatea economică e considerată un tot unitar şi
în care informaŃiile de bază provenite de la sectoarele de activitate sunt prelucrate în toate
felurile considerate utile şi se folosesc apoi la nivelurile de conducere în vederea planificării,
executării şi a efectuării controlului.
Realizarea sistemului integrat de prelucrare a datelor, trebuie să dispună de un model
ce să reprezinte activitatea economică, drept un sistem integrat unitar.
Modelul tradiŃional se prezintă astfel:
Conducerea firmei AcŃionari
Contabilitate
Desfacere Personal
ProducŃie Aprovizionare Financiar
Figura 1.3 Exemplu de flux al informaŃiilor dintr-o unitate (firmă) [21]
1.4. Fluxul informaŃional

Acesta este cantitatea de date şi de informaŃii care parcurg un anumit circuit
informaŃional.
În cadrul unei firme se disting trei fluxuri informaŃionale [44]:
• fluxul de informaŃii produse de firmă pentru ea însuşi
27
• fluxul de informaŃii prelevate din exterior şi utilizate de firmă

• fluxul de informaŃii produse de firmă cu destinaŃie în exterior
Fiecare din cele trei fluxuri are două tipuri de informaŃii, anume: informaŃii de
activitate şi informaŃii de convieŃuire.
InformaŃiile de activitate sunt utile firmei pentru exercitarea funcŃiilor sale.
InformaŃiile de convieŃuire sunt cele care permit convieŃuirea împreună şi în relaŃii cu
alŃii şi care pot influenŃa comportamentul acestora.
Atât în interiorul firmei cât şi în exteriorul ei, fluxurile informaŃionale se pot grupa
astfel: fluxuri verticale şi fluxuri orizontale.
În literatura de specialitate se mai menŃionează o a treia grupă, anume: fluxurile oblice
ce se realizează între anumiŃi manageri şi compartimentele ce nu sunt în subordinea lor
1.5. Circuitul informaŃional

Este un ansamblu de compartimente, locuri de muncă sau circuite logice pe care îl
parcurg datele şi informaŃiile din momentul colectării lor sau intrării lor în firmă şi până în
momentul arhivării lor sau furnizării în exterior.
Orice circuit este format din noduri, în care sunt oameni, între care s-a stabilit legături
informaŃionale directe sau tehnologii informaŃionale care recepŃionează, stochează sau
transmit informaŃii.
Circuitul informaŃional nu Ńine cont întotdeauna de liniile de autoritate a structurii
firmei.
Nu se pot stabili circuite standard pentru o aplicaŃie, deoarece fiecare aplicaŃie este un
caz particular, cel puŃin din punct de vedere al entităŃii unde este implementată.
1.6. FuncŃiile sistemului informaŃional

Sistemul informaŃional trebuie să realizeze patru funcŃii principale, anume:
înregistrarea, memorarea, prelucrarea şi comunicarea.
FuncŃia de înregistrare, arată că o dată sau o informaŃie poate exista, dar atât timp cât
ea nu este percepută, nu se poate spune că este utilizată şi că face parte din sistemul
informaŃional. În cadrul culegeri şi înregistrării datelor se urmăreşte şi eliminarea unei
deficienŃe ce se manifestă în funcŃionarea sistemelor informaŃionale, ca : distorsiunea şi
redundanŃa.
FuncŃia de memorare constă în stocarea datelor pe purtătorii tehnici de mare
capacitate în vederea utilizării lor în cadrul unor procese de prelucrare ulterioară.
FuncŃia de prelucrare, ce se poate face cu muncă manuală, intelectuală sau cu
tehnologiile informaŃionale. Ea constă în: accesul la date şi manipularea datelor.
FuncŃia de comunicaŃie cunoaşte forme extrem de variate situându-se atât la nivelul de
schimb, între funcŃiile deja enumerate cât şi în interfaŃa dintre sistemul informaŃional însuşi şi
sursele sau utilizatorii săi. Cercetările sunt consacrate la prezentarea schimbului de date
informatice.
Acesta este o tehnologie informaŃională ce permite transferul automat al datelor
structurate între calculatoarele partenerilor comerciali.
28
PerfecŃionarea sistemelor informaŃionale
1.7. PerfecŃionarea sistemelor informaŃionale

În mod tradiŃional obiectivele acestui demers sunt în număr de patru, anume [21]:
• adecvarea investiŃiilor în sistemul informaŃional cu obiectivele strategice ale
firmei
• prelucrarea informaŃiilor pentru obŃinerea de avantaje concurenŃiale
• atingerea unei gestiuni eficace şi eficiente a sistemului informaŃional
• ajunge la alegeri coerente în termenii tehnicii şi arhitecturii
Pentru managementului sistemelor informatice avem cinci tipuri de abordări, anume:
Abordarea adecvată, arată că strategia globală a firmei este determinată, în ce priveşte
dezvoltarea sistemelor informaŃionale.
Abordarea metodologică, propune utilizarea unei metode formale pentru a clasifica
strategia de dezvoltare a sistemelor informaŃionale, metodă a cărui promotor este responsabil
cu sistemul informaŃional şi a cărei aplicare este încredinŃată de cele mai multe ori
consultanŃilor externi.
Abordarea bugetară constă în supunerea proiectelor de aplicaŃii aprobării conducerii,
proiecte ce sunt aprobate sau refuzate după studierea bugetului, operaŃie ce se face utilizând
procedurile de control financiar valabile firmei.
Abordarea tehnică se bazează pe metodele de analiză de firmă în care funcŃionarea
acesteia este schematizată cu ajutorul diagramelor ce stau la baza unui proiect de arhitectură
generală a sistemului informaŃional ce trebuie dezvoltat.
Abordarea organizaŃională, construieşte într-o manieră evolutivă, ca urmare a unui
proces continuu de decizii şi alegerii efectuate prin confruntarea permanentă dintre
organizaŃie şi sistemul informaŃional.
1.8. Sistemul informatic

Sistemul informatic este un ansamblu coerent structurat, făcut din echipamente
electronice de calcul şi comunicaŃie, programe, procese, proceduri automate şi manuale,
utilizat ca instrument de prelucrare automată a datelor în cadrul unui domeniu concret de
activitate [7] [44].
Sistemul informatic economic este conceput şi funcŃionează la nivelul unei unităŃi
economice, în vederea asigurării informaŃiilor necesare conducerii şi desfăşurării în bune
condiŃii a activităŃii.
Un sistem informatic preia şi dezvoltă o parte din baza informaŃională şi operaŃiile de
prelucrare ale sistemului informaŃional al unităŃii şi devine o componentă a acestuia. Pe baza
acestui punct de vedere, sistemul informatic poate fi privit ca un sistem informaŃional
automatizat.
Sistemul informatic asigură conservarea (memorarea) şi prelucrarea automată a unei
părŃi a informaŃiilor din unitatea beneficiară, ce vor îndeplini cerinŃe ca: asigurarea,
simplificarea şi ameliorarea lucrărilor şi procedurilor informaŃionale ce propun simpla
execuŃie a unor operaŃii şi prelucrări de rutină; asistarea şi sprijinirea procesului de
conducere şi în mod deosebit a procesului decizional; este un instrument de simulare, ce
permite evaluarea rigidă a consecinŃelor previzibile ale fiecărei decizii şi adoptarea celei mai
eficiente.
Informatizarea cuprinde cele mai mari părŃi ale sistemului informaŃional ce sunt
formalizabile, prin definirea unor funcŃii de transformarea intrărilor în ieşiri. Prin elaborarea
de modele adecvate se permite ca unele acte decizionale să fie formalizate şi să fie
transformate calculatorului.
29
Sistemul întreprindere
Subsistemul decizional
MEDIUL EXTERIOR
Decizii
InformaŃi
Flux informaŃional Subsistemul informaŃional
Decizii Date
Fluxuri materiale
şi finaciare Subsistemul operaŃional
Figura 1.4 Locul sistemului informatic [21]

Folosirea calculatorului la rezolvarea unui grup omogen de lucrări sau probleme ale
beneficiarului, constituie o aplicaŃie informatică, cu observaŃia că un sistem informatic poate
cuprinde mai multe aplicaŃii informatice. Sfera de cuprindere a unei aplicaŃii, este determinată
de omogenitatea funcŃională a prelucrărilor realizate şi de delimitarea dintre procesele
formalizabile şi neformalizabile.
Sistemul informatic integrat asigură prelucrarea unică a fiecărei informaŃii şi difuzarea
acesteia tuturor aplicaŃiilor ce o solicită.
Unele căi de realizare a integrării sistemelor: memorarea fiecărei informaŃii în aşa fel
ca să corespundă integral tuturor cerinŃelor specifice ale aplicaŃiilor şi să fie disponibilă
pentru fiecare din ele; transmiterea informaŃiilor între aplicaŃii se face sub formă de fişiere
de interfaŃă ce asigură joncŃiunea acestora.
Fizic integrarea poate fi realizată prin intermediul unei reŃele locale de calculatoare, ce
asigură distribuirea colecŃiilor de date memorate între compartimentele unităŃii economice, ce
sunt în relaŃii ierarhice sau liniare, în vederea furnizării necesarului de informaŃii pentru
fiecare dintre acestea.
La nivelul unei firme sistemul informaŃional asigură legătura între sistemul decizional
şi sistemul operaŃional, în acest scop presupune desfăşurarea următoarelor activităŃi:
• introducerea datelor referitoare la sistemul operaŃional
• prelucrarea datelor cu scopul asigurării informaŃiile utile procesului decizional
• obŃinerea informaŃiilor solicitate
• efectuarea controlului şi urmăririi respectării deciziilor
Dacă pentru desfăşurarea acestor activităŃi se utilizează cu preponderenŃă calculatorul,
sistemul informaŃional devine sistem informatic.
Sistemul informatic nu se poate identifica cu cel informaŃional, fiind inclus în acesta,
deşi tendinŃa actuală este cea de convergenŃă a sistemului informatic către cel informaŃional,
prin creşterea gradului de automatizate, cu toate că există activităŃi specifice umane care nu
vor putea fi automatizate.
30
Sistemul informatic
Sistemul informatic se interpune între sistemul decizional şi cel operaŃional, conform

figuri 1.4.
Sistemul informatic este un ansamblu structurat şi corelat de proceduri şi echipamente
electronice de calcul, ce permit prelucrarea automată a datelor şi obŃinerea de informaŃii.
O imagine mai completă a sistemului informatic al unei firme este prezentată în figura
următoare:
SISTEM
INFORMAłIONAL I
(inclusiv informatic) Sistem de E
sprijinirea Ş
conducerii I
strategie R
I
Sistem de sprijinire
procesului decizional
Sistem de informare a conducerii operative
Sisteme de prelucrare a tranzacŃiilor
Comercial Personal ProducŃie Financiar Contabil
INTRĂRI
Figura 1.5 Imagine mai completă a sistemului informatic [44]

Sistemul informatic are următoarele componente: cadrul organizatoric al firmei şi
datele vehiculate de sistemul informaŃional, resursele umane, dintre care amintim: analiştii
proiectanŃi, programatorii, inginerii de sistem sau administratorii de reŃea, operatorii şi
controlorii de date; metodele şi tehnicile de proiectare a sistemelor informatice; elementele
electronice de calcul cu toate perifericele aferente prelucrării datelor; sistemul de programe
utilizat sau softul aferent.
Realizarea oricărui sistem informatic implică asigurarea tuturor elementelor
componente menŃionate anterior, orice omitere generând lipsa de viabilitate a sistemului.
1.8.1. Sisteme informatice de gestiune (SIG)

Acestea cuprind patru componente independente: domeniile de gestiune, datele,
modelele şi regulile de gestiune.
Domeniile de gestiune corespund funcŃiilor agenŃilor economici, adică acŃiunilor
omogene care se desfăşoară în cadrul lor şi anume: de cercetare –dezvoltare, de producŃie, de
comercial, de personal şi financiar-contabil, etc., cu luarea în considerare a interacŃiunilor
31
dintre ele. În domenii prelucrările de date sunt structurate pe patru nivele, astfel: tranzacŃional,
operaŃional, tactic şi strategic.
Datele vehiculate şi prelucrate de SIG, indiferent de natura lor, de caracterul lor
formal sau informal sau de suportul pe care se află, reprezintă materia primă a oricărui sistem
de gestiune.
Modelele de gestiune reprezintă procedurile proprii ale unui domeniu, ca de exemplu:
tehnologia de fabricaŃie specifice domeniului producŃie, vânzările specifice domeniului
comercial, contabil specific domeniului financiar-contabil.
Regulile de gestiune ne permit prelucrarea datelor şi utilizarea informaŃiilor în
conformitate cu obiectivele sistemului.
Sistemele informatice de gestiune actuale sunt sisteme integrate. FuncŃia de bază a
SIG constă în prelucrarea datelor disponibile în vederea obŃinerii informaŃiilor necesare
subsistemului decizional. El conŃine trei componente de bază, anume: intrările, prelucrările şi
ieşirile.
1.8.2. Tipuri de sisteme informatice

În activitatea practică se disting patru tipuri de sisteme informatice, anume [7] [21]:
• sistem de prelucrare a tranzacŃiilor – care va înregistra tranzacŃiile zilnice
ca: comenzile clienŃilor, facturile, nivelul stocurilor, consumurile şi obŃinerea
produselor din fabricaŃie
• sistem informatic de conducere (management) – care comprimă datele în
rapoarte standard pentru managerii de nivel mediu
• sistem suport de decizie – care oferă mijloace eficiente pentru analiza
proceselor şi fenomenelor economice
• sistemul suport al executivului sau sistem informatic al executivului – care
este uşor de folosit şi prezintă informaŃiile în formular prestabilit, fiind folosit
de managerii de nivel înalt ce supraveghează strategiile de dezvoltare şi bunul
mers al agentului economic
• alte sisteme informatice
1.8.2.1. Sisteme de prelucrare a tranzacŃiilor (SPT)

TranzacŃiile sunt evenimente prin care se înregistrează sistematic fenomenele şi
procesele economice sau activităŃile economice a unui agent economic.
SPT -urile sunt aplicaŃii ale sistemului informaŃional care permit culegerea, stocarea şi
prelucrarea zilnică a datelor rezultate din desfăşurarea tranzacŃiilor, asigurând actualizarea
bazei de date. Ele se mai numesc sisteme de prelucrare a datelor.
Gestionarea datelor este o funcŃie de bază a acestuia şi se asigură prin rutine de
actualizare şi memorare a datelor.
Analiza şi proiectarea sa trebuie să se concretizeze în timpul de răspuns, volumul
tranzacŃiilor, precizia şi serviciile oferite.
Un SPT ajută agentul economic să Ńină evidenŃa operaŃiunilor sau acŃiunilor curente şi
să le înregistreze în baza de date.
Cel mai semnificativ SPT se referă la sfera contabilităŃii, pe care-l ilustrăm în
continuare (Figura 1.6):
32
Sistemul informatic
Comercial Contabi Produc.

D
O Strategic
M Modele Reguli de
E Tactic de gestiune
N gesti-
I OperaŃion une
I .al
TranzacŃional
D Specifice
A
T
E Comune
Figura 1.6 Cel mai semnificativ SPT care se referă la sfera contabilităŃii [21]
1.8.2.2. Sisteme informatice de conducere (SIC)

Aceste sistem sunt proiectate pentru realizarea de rapoarte cerute de planificarea,
urmărirea şi controlul activităŃilor economice dintr-o firmă, adică ele satisfac cerinŃele
conducerii operative. Oferă managerului parametrii activităŃii desfăşurate şi permite să ia
decizii cu caracter repetitiv fără implicaŃii majore în viaŃa firmei.
SIC -ul este un sistem de aplicaŃii informatice care se ocupă cu elaborarea de rapoarte
sub formă standard necesare organizării conducerii operative a firmei.
SIC -ul produce informaŃii bazate pe modele matematice sau statistice. InformaŃiile
detaliate pot fi utilizate pentru operaŃiile de conducere sau reglare a cerinŃelor, informaŃiile
agregate rezultate din prelucrarea informaŃiilor detaliate ajută pentru a vedea tendinŃele şi
eventualele probleme ce pot apărea , iar informaŃiile de excepŃie rezultă din filtrarea datelor
care nu se supun unei reguli stabilite.
SIC -ul are nevoie de un sistem de baze de date de management, cu care reuneşte
bazele de date ale diferitor departamente şi produce rapoarte predeterminate.
El poate da în esenŃă trei categorii generale de rapoarte, anume:
• rapoarte periodice întocmite la intervale regulate de timp, exemplu:
săptămânal, decadal, lunar sau trimestrial
• rapoarte de excepŃie ce atrag atenŃia asupra acŃiunilor sau evenimentelor
neobişnuite
• rapoarte la cerere, ce se realizează în conformitate cu cerinŃele decidentului
1.8.2.3. Sistem suport de decizie (SSD)

SSD -ul este un sistem de aplicaŃii informatice ce asigură utilizatorilor informaŃii
orientate pe decizii, adică informaŃii referitoare la diverse situaŃii care apar în luarea
deciziilor.
Dacă sistemul este utilizat direct de conducerea executivă a firmei se mai poate numi
sistem de informare executivă.
33
SSD -ul nu este decât un instrument în mâna decidentului căreia îi furnizează

informaŃii utile suportului procesului decizional.
În particular acestea sunt de regulă proiectate ca suport al deciziilor nestructurate,
adică pentru deciziile ce nu se pot prevede anticipat.
SSD -ul asigură urătoarele tipuri de suporturi decizionale:
• identificarea problemelor sau oportunităŃilor de luare a deciziilor
• identificarea soluŃiilor posibile sau a deciziilor adecvate
• accesul la informaŃiile necesare în rezolvarea unei probleme sau la luarea unei
decizii
• analiza deciziilor posibile sau a variabilelor care au impact asupra deciziei
Analiza şi proiectarea unui depozit de date şi a unui SSD utilizează multe instrumente
şi tehnicile informaticii manageriale. SSD -ul ajută pe cei care iau decizii în analiza situaŃiilor
neprevăzute, tot el se poate folosi în munca colectivă din firmă.
SSD -ul este un instrument flexibil pentru analiza datelor în vederea obŃinerii unor
rapoarte ce nu au o formă precisă.
Acest sistem este alcătuit din patru părŃi, anume:
• utilizatorul care este persoana ce trebuie să ia decizii şi de obicei este un
manager de nivel mediu
• softul (produsul program), care este sistemul de operare plus programele ce
lucrează în background pentru a putea manipula procedurile operaŃionale şi de
obicei produsul program asociat acestui SSD are un meniu sau icoane
• datele sunt stocate într-o bază de date şi sunt de două tipuri: interne şi externe,
unde cele interne sunt din firmă, iar cele externe sunt din afara firmei
• modelele decizionale care-l conferă capacitatea analitică şi utilizează trei
modele, anume: strategice, tactice şi operaŃionale
Un exemplu de astfel de sistem în figura următoare:
PROBABILISTICE
DE OPTIMIZARE DESCRIPTIVE
DETERMINISTICE
Figura 1.7 Exemplu de SSD [23]

Modelele de optimizare caută să identifice punctele de maximizare sau minimizare şi
pot fi imperative (what to do) sau predictive (what will happen).
Modelele descriptive descriu comportamentul sistemului, nu sugerează condiŃiile de
optimizare dar atenŃionează asupra „punctelor problemă”.
Modelele probabilistice se folosesc pentru a descrie natura mai puŃin previzibilă a
sistemului utilizând intrări probabilistice (nu toate intrările sunt cunoscute cu certitudine) şi
generând ieşiri probabilistice.
DSS -urile pot fi considerate ca nivelul de vârf al aplicaŃiilor destinate conducerii.
Avantajele utilizării DSS:
• Posibilitatea testării unor numeroase scenarii
• Pot fi revăzute efectele modificării simultane ale mai multor variabile
• Oferă facilităŃi grafice dinamice
34
Sistemul informatic
• Stimularea creativităŃii decidentului

• FacilităŃile deosebite oferite în planul formării/perfecŃionării managerilor
Dezavantajele utilizării DSS:
• Pot fi omise în model variabile importante
• Modelele pot să nu corespundă întocmai realităŃii fapt ce influenŃează negativ
decizia
• Se apelează preponderent la ecuaŃii liniare pentru a uşura programarea
• Modelul poate prezenta erori importante dar greu de identificat
În funcŃie de soluŃia TI utilizată în realizarea DSS acestea se clasifică:
• Sisteme interactive de asistare a deciziei (SIAD/DSS)
• Sisteme expert
Un SIAD este o aplicaŃie în care funcŃia de evaluare se prezintă în fiecare etapă sub
forma unor modele proiectate în funcŃie de natura deciziei ce trebuie luată.
Sisteme suport de decizie (DSS – Decision Support Systems) reprezintă sisteme
informatice interactive cu rolul de a asista managerii (plan strategic) în rezolvarea unor
probleme semistructurate folosind în acest scop modele şi baze de date specializate pe
probleme bine definite:
• DSS nu formulează decizii ci, ajută managerii în luarea unor decizii mai bune
• DSS oferă middle şi top managerilor rapoarte (ale căror formate pot fi uşor
modificate), oferă posibilitatea derulării de analize de tip „what if” şi realizării
de grafice
• SusŃin decizii specifice unor situaŃii având caracter recurent sau cerinŃe ad
hoc
• Sprijină managerii în soluŃionarea unor probleme semistructurate
• SusŃin decizii în domenii cum ar fi: trezorerie/finanŃe, planificare strategică,
marketing etc…
1.8.2.4. Sisteme suport ale executivului (SSE)

Acestea sunt sisteme simplificate, special proiectate pentru decidenŃii de nivel înalt,
iar utilizarea acestora necesită ceva pregătire.
De regulă are ca suport un soft sofisticat care poate extrage date din bazele de date ale
firmei în forme care au o semnificaŃie directă (informaŃii sintetice, grafice, tabele, etc.). Aici
informaŃia este afişată într-o formă foarte condensată şi cu o grafică îngroşată.
El permite decidenŃilor de nivel înalt a firmei să aibă acces direct la informaŃii despre
performanŃele acesteia. Ele au poştă electronică ce permite managerilor să comunice direct cu
decidenŃii.
SSE -ul poate fi proiectat să extragă informaŃii din baze de date exterioare firmei, ca
de exemplu: serviciile ştirilor de afaceri.
1.8.2.5. Sistem informatic standard (SIS)

El este format dintr-un set finit de metode, tehnici, procedee, modele, strategii,
instrumente, sisteme de tehnică de calcul, sisteme de comunicaŃie a datelor, 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 agentului economic şi a atributelor sistemului de
gestiune.
35
Toate aceste elemente au rolul de a asigura o funcŃionalitate optimă şi o reglare de tip

conexiune inversă (feed-back) a întregului sistem aferent unui agent economic, în condiŃii de
eficienŃă economică şi rentabilitate financiară acceptabile.
Deci, SIS primeşte datele de la sistemul operant şi prin intermediul unei baze de
proceduri asociative (BP), care asigură prelucrarea multiplă a acestora, în conformitate cu un
sistem procedural 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 SIS.
Practic, SIS foloseşte colecŃii de date (CD) organizate sub formă de:
• baze de date
• baze de tabele
SIS foloseşte în mod preponderent programarea procedurală, care descrie şi utilizează
proprietăŃile specifice algoritmilor de calcul şi prelucrare, reunite practic prin intermediul
conceptului de bază de proceduri.
Intrările SIS sunt asigurate prin tranzacŃii externe generate de operaŃiile economice
desfăşurate la nivelul subsistemului operant, operaŃii care generează un flux de date care vor
determina operaŃii de actualizare asupra bazei de date sau asupra bazei de tranzacŃii.
Prelucrările SIS sunt de tip procedural şi au la bază algoritmii specifici agentului
economic.
Obligatoriu, aceste prelucrări Ńin seama şi de algoritmii derivaŃi din cadrul legislativ
general în materie şi de particularităŃile aplicării sale la specificul beneficiarului.
Ieşirile SIS sunt obŃinute în urma aplicării prelucrărilor asupra tranzacŃiilor şi sunt
concretizate în următoarele tipuri:
• rapoarte / situaŃii / liste
• indicatori sintetici
• grafice
• ieşiri către alte SIS
Un astfel de sistem este arătat în figura ce urmează:
Top management
Sisteme
strategice
Sisteme suport pentru Specialişti (knowledge workers)

specialiştii firmei
Management tactic
Sisteme operaŃionale (middle manegers)
Sisteme pentru automatizarea FuncŃionari

muncii de birou şi comunicaŃii
Infrastructura informaŃională şi TPS
Figura 1.8 Sistem informatic standard [24]

Alături de definirea strategiei de afaceri este necesară definirea strategiei sistemului
informatic şi aceasta deoarece:
36
Sistemul informatic
• sistemul informatic susŃine managerii, prin informaŃiile furnizate, în

conducerea şi controlul activităŃii în vederea atingerii obiectivelor strategice
ale organizaŃiei
• sistemele informatice sunt deschise şi flexibile adaptându-se permanent
cerinŃelor impuse de mediul dinamic în care operează firma
• promovarea soluŃiilor TI susŃine organizaŃia în consolidarea şi dezvoltarea
afacerii (ex.:comerŃul electronic, e-banking etc)
• sistemul informatic oferă informaŃiile necesare controlului îndeplinirii şi
adaptării planurilor operaŃionale şi strategice ale organizaŃiei
• organizaŃia trebuie să cunoască şi să controleze riscurile legate de
implementarea noilor tehnologii şi adaptarea sistemului informatic la noile
cerinŃe
• stabilirea unor standarde la nivelul sistemului informatic care au menirea de a
preciza caracteristicile şi performanŃele hard şi soft ale componentelor ce
urmează a se achiziŃiona şi ce metodologii urmează să se utilizeze în
dezvoltarea sistemului
1.8.2.6. Sistemul expert (SE)

El are la bază conceptul de inteligenŃă artificială (IA) prin care se asigură în principal
simularea proceselor din cadrul unui raŃionament natural uman. SE asigură declanşarea,
utilizarea, interpretarea şi multiplicarea unor raŃionamente artificiale prin intermediul unui
generator de sistem expert, folosind inteligenŃa artificială, care permite stocarea, utilizarea şi
interpretarea cunoştinŃelor experŃilor umani dintr-un domeniu, utilizate apoi pentru rezolvarea
unor probleme specifice acelui domeniu, pentru înlocuirea raŃionamentului uman cu unul
artificial, folosind cunoştinŃele independente în raport cu mecanismul raŃionamentului.
Conceptul de inteligenŃă naturală este dificil de prezentat, neexistând un acord asupra
criteriilor care o caracterizează şi conŃine următoarele caracteristici [23]:
• ansamblul de cunoştinŃe mentale având drept obiectiv cunoaşterea conceptuală
şi relaŃională care se opune senzaŃiei şi intuiŃiei
• facultatea de a cunoaşte lucrări, fapte, idei şi de a le înŃelege
• aptitudini de a se adapta la noi situaŃii
• capacitatea de a reflecta şi de a comunica cu alŃii
Sistemele expert întrebuinŃează o parte din raŃionamentul uman apropiindu-se uneori
de el şi uneori îndepărtându-se de acesta. Ele nu pot face în perioada informaticii inteligenŃei
artificiale:
• să creeze la fel ca omul, deşi vor conŃine informaŃii despre toate creaŃiile
trecute ale omului
• să opereze cu sensuri fenomenologice
• să intuiască la fel ca omul, deşi vor conŃine intuiŃii vechi ale omului
Un sistem expert reproduce comportamentul unui expert. Cunoaşterea domeniului de
expertiză este dobândită în vrac, sub forma regulilor de producŃie. El utilizează aceste reguli,
Ńinând cont de situaŃia descrisă de consultant pentru a propune un diagnostic, pentru a stabili
un bilanŃ sau pentru a declanşa un mecanism de alarmă sau de reglare.
Sistemul expert este un produs informatic care apelează inteligenŃa artificială pentru
rezolvarea problemelor dintr-un domeniu de activitate, folosind în acest scop cunoştinŃele şi
experienŃa experŃilor umani din acel domeniu, captată şi memorată pe un purtător tehnic
informaŃii.
SE sunt dedicate anumitor domenii şi conŃin trei elemente fundamentale pentru
reprezentarea cunoştinŃelor, anume [23]:
37
• baza de cunoştinŃe
• baza de fapte
• generatorul de sistem expert
Baza de cunoştinŃe (BC), ce conŃine sistemul de cunoştinŃe specifice domeniului,
inclusiv relaŃiile dintre acestea. CunoştinŃele pot fi reprezentate prin mai multe metode, dintre
care cele mai importante sunt regulile de producŃie, cadrele şi reŃelele semantice. BC este
supusă la două procese esenŃiale ca: crearea sa şi validarea sa.
Bazele de cunoştinŃe conŃine ansamblul de informaŃii dintr-un anumit domeniu,
furnizat de unul sau mai mulŃi experŃi umani. InformaŃiile furnizate de expertul uman trebuie
formalizate de către inginerul de cunoştinŃe sau cognoticianul. Aceasta fiind o problemă
complexă şi e una din greutăŃile sistemului expert. InformaŃiile furnizate de expert şi cele
furnizate de cognotician sunt introduse în baza de cunoştinŃe, sub forma unor reguli.
Baza de fapte (BF), ce conŃine datele ce fac obiectul unei probleme de rezolvat din
domeniu respectiv, la care se pot adăuga faptele rezultate în urma raŃionamentelor artificiale
efectuate de către motorul de inferenŃe (MI) asupra bazei de cunoştinŃe.
Baza de fapte conŃine datele privind starea de fapt a unui fenomen sau proces care
generează o problemă care trebuieşte rezolvată. Mesajele sale, presupun extrase inserate în
momentul elaborării sistemului expert, fie de operatorul ce-l foloseşte, sau deducându-se din
raŃionamentele operate de program.
Motorul de inferenŃă este elementul de prelucrare care pornind de la fapte şi folosind
procedeele numite metareguli, clauze sau scheme, activează baza de cunoştinŃe, construind
raŃionamente ce conduc la noi fapte. Programul apropie în mod judicios elementele din
celelalte componente de ansamblu, precedente, evitând examinarea sistematică a tuturor
faptelor şi regulilor. Separarea între fapte, reguli de judecată care redau formal intuiŃiile şi
convingerile experŃilor umani şi structurile de control care manipulează cunoaşterea din baza
de cunoştinŃe, în funcŃie de starea problemei în scopul rezolvării acesteia, face ca sistemul
expert să fie un program de tip nou. Sistemul expert apare ca un program care construieşte
programe sau ca un program cu inteligenŃă.
Se poate aprecia că aceste componente sunt importante în crearea efectului de
comportament inteligent.
SE foloseşte programarea declarativă prin intermediul căreia regulile sunt furnizate
independent de înlănŃuirea lor, cea ce se traduce prin definirea regulilor separat faŃă de metoda
care le va folosi. Metoda este implementată într-o componentă soft, denumită motorul de
interfeŃe (MI), care face parte din generatorul de sisteme expert.
Modul de reprezentare al cunoştinŃelor (MRC), care asigură conversia şi transmiterea
informaŃiilor corespunzătoare furnizate de expertul uman din acest domeniu, acesta le
furnizează inginerului de cunoştinŃe şi care la rândul său le aduce într-o formă compatibilă cu
cunoştinŃele interne, fizice, de memorare solicitate de către acest modul;
Precizăm că regulile de producŃie (RP) reprezintă modalitatea esenŃială de
reprezentare a cunoştinŃelor folosind logica propoziŃiilor. Aici, faptele şi regulile sunt
reprezentate prin entităŃi constante sau generice, specificate prin intermediul variabilelor, cu
folosirea metodei de reprezentare a cunoştinŃelor prin reguli de producŃie variabile (RPV).
Regulile de producŃie pot fi declarate în două moduri [23]:
• motorul de inferenŃe – care asigură rezolvarea practică a unei probleme din
domeniul respectiv, pe baza faptelor furnizate, utilizând cunoştinŃele necesare
prin dezvoltarea unu raŃionament artificial, care poate conduce la noi fapte
• generatorul sistemului expert (GSE) – care este un sistem de programe
dedicate, conectat la BC, care foloseşte cunoştinŃele stocate aici pentru a
modifica datele din BF
38
Sistemul informatic
Domeniile de aplicare sunt foarte diversificate, ce a dus la apariŃia mai multor tipuri de
asemenea sisteme, anume:
• sisteme expert analiste – care examinează datele cantitative şi calitative,
deducând un profil de situaŃie şi estimând riscul asociat acestei situaŃii
• sisteme expert de consiliere – care au ca scop să determine profilul unui
investitor şi portofoliul acestuia, sau consiliază asupra produselor ce convin
bine situaŃiei respective
• sistem expert de structurare şi interpretare de texte – care are ca scop
prezentarea textelor sub formă normalizată, iar sistemele de interpretare
încearcă să determine o reprezentare semantică a textelor şi să propună acŃiuni
potrivite, cum ar fi: clasarea acestora în biblioteci pentru o mai buna referire;
• sistem expert pentru operatori – care face munci cu nivel operaŃional
aplicând un anumit număr de reguli de operare cunoscute de un număr limitat
de persoane;
• sistem expert previzional – care face simulări în diferite sectoare economice
şi studiază scenariile de variaŃie a conjuncturii şi fluctuaŃiei pieŃelor;
• sistem expert organizaŃional – care se foloseşte pentru optimizarea activităŃii
unui serviciu sau compartiment al firmei (agentului economic);
• sistem expert pentru diagnostic şi prescripŃii terapeutice – care stabileşte o
relaŃie între simptome şi relaŃii de un anumit tip, asigurând şi prescrierea
tratamentului (mai ales în medicină), etc.
În practică se pot folosi sisteme multiexpert (SME), definite ca un ansamblu coerent şi
cooperant de SE ce pot funcŃiona atât independent, cât şi în interacŃiune, asigurându-se
proprietăŃile fundamentale legate de modularitatea şi independenŃa părŃilor componente ale
respectivului SME.
SME asigură sintaxa cunoştinŃelor astfel încât modulele sale componente să coopereze
în mod inteligent prin integrarea fiecărui model, pentru ca pe plan cognitiv să se asigure
sintaxa concluziilor modulelor participante.
SME trebuie să asigure funcŃiile de comunicare dintre module, fie printr-un control
centralizat, fie în mod descentralizat.
a) Controlul centralizat, are particularităŃi ca:
• modelele expert comunică între ele prin mesaje
• modulele expert conŃin şi un submodul dedicat comunicaŃiei cu alte module
expert
• permite repartiŃia cognitivă în cazul cunoştinŃelor eterogene
b) Controlul centralizat asigură:
• prin modulul supervizor armonizarea ansamblului SME
• primeşte, transmite, colectează informaŃiile de la module
• unele SME -uri asigură structurarea în module a cunoştinŃelor, a operatorilor
de tipul procedurilor şi a regulilor, dar cu condiŃia ca baza de fapte să rămână
unitară
1.8.2.7. Sistemele interactive de asistare a deciziilor (SIAD) şi sisteme executive (EES)

SIAD-ul este un sistem interactiv destinat să susŃină factorii decizionali umani în
abordarea unor probleme complexe, semistructurate sau nestructurate întâlnite în spaŃiul lor
de decizie şi pentru rezolvarea acestora îşi utilizează propria lor inteligenŃă.
SIAD-urile sunt în interacŃiune cu sistemele informaŃionale ale firmei (agentului
economic) din cauză că cea mai mare parte din informaŃii este stocată şi prelucrată mai întâi
prin sistemele informaŃionale tranzacŃionale înainte de a fi transmis SIAD-ului.
39
SIAD-urile pot fi considerate ca aplicaŃii ale unui domeniu ştiinŃific aflat la frontiera
unor ştiinŃe cu evoluŃie spectaculoasă cum ar fi: cibernetica, inteligenŃa artificială, micro-
electronica, modelarea, informatica, etc.
Caracteristicile SIAD-ului sunt următoarele:
• datorită unicităŃii cazurilor un SIAD necesită un volum mare de informaŃii şi
de un sistem de gestiune a bazelor de date
• are un alt orizont decât alt sistem automatizat, SIAD -ul fiind direcŃionat spre
rezolvarea unei noi probleme apărute
• SIAD-ul realizează obiectivele prin regăsirea şi generarea informaŃiilor.
Regăsirea informaŃiilor este facilitată de flexibilitatea bazei de date şi a SGBD-
ului, care pun la dispoziŃie capacităŃile de accesare a informaŃiilor în moduri
neobişnuite
• majoritatea SIAD-urilor sunt construite pe modele matematice care permit
analizarea unui număr infinit de soluŃii posibile, schimbarea variabilelor unui
model mai uşor decât manipularea unui sistem real, calcularea riscului,
realizarea de costuri mai mici decât costurile simularea unui sistem real
• într-un mediu SIAD, problemele analizate sunt în modificare permanentă, fie
pentru un nou set de condiŃii, care prezintă soluŃii unice irepetabile, fie că
problema se modifică pe măsura creşterii experienŃei decidentului
• SIAD-ul sprijină mai degrabă, decât să înlocuiască judecata managerială
SIAD-ul este un sistem om-maşină care prin dialog, permite factorului decizional să-şi
sporească capacitatea de raŃionament pentru identificarea şi rezolvarea problemelor rău
structurate. Expresia om-maşină pune accentul pe primatul noŃiunii de cuplaj între un sistem
artificial şi o persoană care are propriu mod de gândire, căutând să armonizeze ceea ce apare
pe ecran şi imaginile mentale proprii. NoŃiune de dialog pune în evidenŃă caracteristicile ce
depăşesc sistemele conversaŃionale, dialogul realizat prin SIAD trebuie să permită un control
împărŃit între sistem şi utilizator.
Sistem de gestiune a
modelelor de decizii
Sistemul de gestiune
a dialogului
utilizator SIAD
Decident
Sistem de gestiune a
bazelor de date
Figura 1.9 Structura tehnologică a unui SIAD [7] [21]

Un SIAD este o aplicaŃie în care funcŃia de evaluare se prezintă în fiecare etapă sub
forma unor modele proiectate în funcŃie de natura deciziei ce trebuie luată.
Un SIAD se caracterizează prin:
• baza de modele matematice oferite pentru efectuarea de calcule şi reliefarea
consecinŃelor unor acŃiuni
• decidentul poate “naviga” prin baza de modele în funcŃie de particularităŃile
problemei de rezolvat şi experienŃa sa
• pleacă de la decidenŃi şi de la natura deciziei ce trebuie luată şi a scopului final
urmărit
40
Sistemul informatic
SGBD-ul trebuie să aibă interfeŃe de încărcare şi de asociere a datelor plecând de la

datele interne ale beneficiarului, ca şi datele privilegiate ale decidentului precum şi de date
externe.
SIAD-ul are două tipuri de bază de date: bază de date a cantităŃii şi bază de date
separată logic cu informaŃii de sinteză.
Sistemul de gestiune a modelelor de decizie, are un ansamblu de operaŃii şi modele de
calcul pentru obŃinerea informaŃiei necesare unei decizii.
InterfaŃa decident, e o componentă ce girează partea vizibilă a decidentului.
Gestionarul de dialog, asigură legătura între date, modele şi interfaŃa decident.
Ele folosesc conceptul de inteligenŃă artificială pentru a asigura rezolvarea unor
probleme din domeniul respectiv prin intermediul modelului teoretic de decizie în
incertitudine, denumite şi modele de maximizare a speranŃei funcŃiei de utilitate, elaborat de
Neuman – Margenstern.
Fundamentarea raŃionamentului limitat foloseşte premisele [21]:
• deciziile se referă întotdeauna la un domeniu limitat
• viitorul este greu de anticipat
• cerinŃele unui anumit domeniu sunt întotdeauna în contradicŃie cu cele din alt
domeniu, dacă cele două domenii se analizează separat unul de altul
• SE este o reprezentare a comportamentului uman, comportament ce se bazează
pe modelul raŃionamentului limitat
SIAD -urile au o structură specifică şi anume:
• gestionarea datelor ce se compune din:
o baze de date
o sisteme de gestiune a bazelor de date
• module de management, cu referire la:
o funcŃia de dezvoltare
o funcŃia de servicii
o funcŃia de relaŃii
o funcŃia financiar-bancară
o funcŃia personal-resurse-umane.
• dialogul de gestionare-decizie, care are în vedere sistemul de comunicaŃie, deci
interfaŃa om-maşină.
Sistemele informaŃionale în funcŃie de specificul lor pot conŃine: subsistemul
modelelor de management (SMM), interfaŃa om-maşină (IOM) şi subsistemul de modelare
fundamentală (SMF).
Subsistemul modelelor de management (SMM), este format din module cantitative ce
asigură SIAD -ului proprietăŃi de analiză şi modele structurate în patru clase [23]:
• model strategice (MS), – care asigură responsabilităŃile de planificare şi
gestiune pentru cel mai înalt nivel decizional, fiind de fapt modele pe termen
lung
• modele tactice (MT) – care sprijină gestionarea de nivel mediu, pentru
alocarea şi controlul utilizării resurselor agentului economic
• modelele operaŃionale (MO) – care asigură gestionarea operaŃională în scopul
luării deciziilor zilnice pentru activităŃile operative de la respectivul agent
economic
• modele funcŃional (MF) – care sunt modele asociate funcŃiilor fundamentale
ale agentului economic şi anume: funcŃia de dezvoltare; funcŃia de servicii;
funcŃia de relaŃii; funcŃia financiar - bancară; funcŃia personal – resurse –
umane
41
InterfaŃa om-maşină (IOM), este compusă din:

• limbajul de activare (LA) – care are funcŃiile: opŃiuni de introducerea datelor
şi menŃiuni specifice funcŃiilor utilizate
• limbajul de afişare (LF) – ce este compus din funcŃiile: opŃiuni de ieşire a
datelor şi afişarea multiplă (tabele, grafice, etc.)
• limbajul de cunoştinŃe (BC) – care are funcŃia de cunoştinŃe a domeniului
necesar utilizării SIAD -ului.
IOM -ul asigură următoarele funcŃii:
• interacŃiuni în diverse moduri de dialog
• multitudinea dispozitivelor de intrare – ieşire
• capacităŃi grafice multiple, multiferestre, etc…
• instruire prin exemple
Fizic, un IOM conŃine trei elemente: utilizatorul, sarcina şi aplicaŃia SIAD -ului, care
sunt interconectate între ele.
Subsistemul modulelor fundamentale (SMF), care asigură crearea şi validare bazelor
cu care interacŃionează un SIAD într-un domeniu şi anume:
• modulele de date pentru BD orientate spre obiect, cu baze de date orientate
spre obiect
• module de cunoştinŃe multiutilizator, cu baze de cunoştinŃe
• module de cooperare cu baze de date obiectuale şi multimedia, cu baze de
dialog
EIS (Executive Information Sistem)-urile sunt aplicaŃii destinate să pună la
dispoziŃia managerilor toate informaŃiile de care ei au nevoie pentru a-Ńi duce la bun sfârşit
misiunea.
Caracteristicile principale ale acestuia sunt:
• calitatea prezentării –obŃinută prin utilizarea pictogramei pentru ghidarea în
aplicaŃie, a graficelor pentru analiza tendinŃelor, etc…
• ergonomie adaptată – care permite o înşiruire instantaneea modului de
utilizare a aplicaŃiei
• posibilităŃi de zoom – asupra datelor, care se mai numeşte drill down
• asigură condiŃii pentru conducerea prin excepŃie
• conŃine o serie de funcŃii simple de modelare şi simulare precum şi de funcŃii
birotice
Structura tehnologică a EIS -ului se bazează pe conceptul de hypertext. Acest concept
determină o mutaŃie profundă în modul de acces a informaŃiei.
EIS -ul este structurat pentru a permite managerului să cunoască starea de fapt a firmei
(interne sau externe), în timp se SIAD -ul este cel mai adesea dedicat unui tip de problemă
pentru a permite analize mai complexe.
SIAD -urile servesc la culegerea informaŃiei, la manipularea sub formă
multidimensională, la analiza ei, la modelare şi simulare, iar EIS- urile sunt înainte de toate
produse informatice de prezentare a unei informaŃii filtrate. EIS -ul este răspunsul la nevoile
tuturor responsabilităŃilor care trebuie să acceadă uşor şi repede la informaŃie pertinentă, fără
să fie nevoiŃi să înveŃe utilizarea unui sistem informatic şi corespunde unui evantai care
cuprinde de la managerul general până la responsabilul de entităŃi operaŃională.
1.8.2.8. Sistemul informaŃional contabil

Contabilitatea ca principala sursă de informaŃii privind activitatea oricărei firme,
devine un instrument esenŃial în procesul elaborării deciziilor, în analiza şi evaluarea
performanŃei acesteia. Contabilitatea este partea integrantă a sistemului informaŃional al
42
Sistemul informatic
firmei, deci, ea poate deveni la rândul ei un sistem şi anume Sistemul InformaŃional Contabil
(SIC).
Acesta poate fi definit ca un ansamblu organizat de resurse: umane, materiale, date
contabile, mijloace şi proceduri de culegere, memorare, prelucrare şi comunicare a
informaŃiei contabile.
Contabilitatea este deci, un subsistem informaŃional integrat în sistemele de reglare,
care asigură: culegerea, stocarea, prelucrarea şi comunicarea informaŃiilor privind gestiunea
patrimoniului şi a proceselor interne care au loc, precum şi informaŃii privind reglementare
raporturilor financiare şi juridice cu alte firme din cadrul macrosistemului.
În practică avem sisteme de contabilitate cu un singur circuit şi cu două circuite.
Sistemul cu un singur circuit (monoist, integrat), care organizează conturile intr-un
flux al circuitului economic: capital – aprovizionare – producŃie – desfacere - încasare,
atât pentru operaŃiile ce privesc relaŃiile cu terŃii, cât şi pentru cele ale gestiuni interne.
Sistemul cu dublu circuit (dualist), care organizează conturile în circuite distincte,
anume: un circuit cuprinde conturile care au ca obiect operaŃiile patrimoniale legate de
schimburile şi relaŃiile cu terŃii, precum şi rezultatele financiare (contabilitatea financiară) şi
altul care conŃine conturile unde se înregistrează producŃia, costurile şi rentabilitatea
produselor (contabilitatea de gestiune). Se prezintă în următoarea figură:
Documente SituaŃia costurilor pe

Actualizare Consultare 1 comenzi
SituaŃia abaterilor de la
costurile anticipate
BD ....................................
...
Consultare 2 BalanŃa de verificare

Registrul jurnal
Cartea Mare
Figura 1.10 Sistem cu dublu circuit [21]

Primul este în Ńările anglo-saxone, iar al doilea în Ńările ComunităŃii Europene.
Transformările profesie de contabil se pot reliefa cu uşurinŃă dacă se scindează
evoluŃiile previzibile ale contabilităŃii pentru a le studia separat. Sistemul contabil poate fi
descompus în şapte nivele, astfel:
• aplicaŃie
• prezentare
• control
• gestiune AplicaŃie contabilă
• conformitate
• logic
• fizic
Nivelul fizic, conŃine caracteristicile şi tehnicile înŃelegerii suportului contabil.
Nivelul logic, asigură descrierea programelor necesare exploatării nivelului fizic,
utilizabile într-o firmă sau companie.
Nivelul conformitate, ce conŃine regulile şi principiile contabile generale.
43
Nivelul gestiune, care regrupează toate regulile contabile interne ale firmei sau
companiei.
Nivelul de control, care regrupează regulile de control necesare pentru gestiunea
informaŃiilor care intră sau ies din firmă sau companie.
Nivelul de prezentare, care ne prezintă modul de afişare a datelor.
Nivelul aplicaŃie, care conŃine parametrii şi serviciile utilizate în programele
informatice ale firmei sau companiei.
Aceste şapte nivele sunt obligatorii pentru formarea ansamblului numit contabilitate.
AgenŃii inteligenŃi sunt mici programe prevăzute pentru a îndeplini unele sarcini ale
utilizatorului, asigurând şi anticipând operaŃiile. Ei au patru caracteristici importante, anume:
• autonomia, care acŃionează fără intervenŃiei exterioară
• asistă pe utilizator la îndeplinirea sarcinilor curente
• autoadaptabil, deci se dezvoltă permanent în contact cu utilizatorul
• inteligenŃă condiŃionată, deci poate lua decizii în anumite condiŃii în locul
utilizatorului
Avem două tipuri de agenŃi, anume:
• sedentari, care sunt destinaŃi să faciliteze convivalitatea dintre utilizator şi
sistemul să de calcul
• înverşunaŃi, care sunt indispensabili în contextul intranetului
Aceştia pot să-şi găsească un loc foarte convenabil când aplicaŃiile informatice fac
apel la componente de provenienŃă diferă, care este dotat cu anumite capacităŃi, agentul
sesizează un anumit comportament sau acŃiune care se repetă, pe care le compară cu regulile
sale şi baza sa de cunoştinŃe. DotaŃi cu inteligenŃă artificială sau nu, agenŃii vor modifica
sarcinile profesiei de contabilitate.
1.8.2.9. Alte sisteme informatice

Firma mai poate folosi şi alte sisteme informatice destinate activităŃilor de birou şi
cele destinate cercetării dezvoltării. Mai pot exista sisteme informatice ce ajută diferite
persoane şi funcŃii. Sistemele informatice de birou sunt proiectate să ajute personalul ce
lucrează cu datele din sistemul obiect. Ele se bazează pe procesarea documentelor, pe
comunicaŃii şi pe stabilirea planului de muncă. Documentele sunt procesate folosind un
procesor de texte, tabele de calcul, tehnologii de prelucrare a imaginilor, etc. ComunicaŃiile
realizându-se prin poştă electronică, mesagerie vocală şi video conferinŃă. Sistemele
informatice destinate cercetării dezvoltării, sunt folosite de cercetători şi personalul ce
lucrează în acest domeniu. Tot aceştia pot folosi sisteme bazate cunoştinŃe pentru a crea
informaŃii în domeniul lor.
1.8.3. Ciclul de viaŃă al unui sistem informatic

El este un proces logic prin care analiştii de sistem, inginerii soft, programatorii de
aplicaŃii şi utilizatorii finali construiesc sistemul informatic. Acesta este un instrument esenŃial
pentru managementul proiectului, instrument ce se utilizează pentru planificarea, execuŃia şi
controlul desfăşurării proiectelor de sistem informatic.
Există o gamă largă de modele ale ciclului de viaŃă al sistemului informatic şi toate au
comun următoarele faze: 1. definirea cerinŃelor utilizatorilor; 2. specificarea cerinŃelor
sistemului; 3. specificarea cerinŃelor soft; 4. proiectarea generală; 5. proiectarea de detaliu; 6.
realizarea componentelor sistemului informatic; 7. testarea componentelor; 8. integrarea
componentelor şi testarea finală; 9. instalarea şi testarea produsului la beneficiar; 10.
exploatarea şi întreŃinerea sistemului; 11. dezvoltarea sistemului în vederea perfecŃionării sale.
44
Sistemul informatic
De regulă aceste faze se regăsesc în marea majoritate a modelelor asociate ciclului de

viaŃă al sistemului informatic şi sunt reunite în cadrul unor etape şi anume [23]:
• analiza sistemului (conŃine fazele 1-3)
• proiectarea generală (conŃine faza 4)
• proiectarea de detaliu (conŃine faza 5)
• realizarea sistemului informatic (conŃine fazele 6-8)
• instalarea sistemului la beneficiar (implementarea sa) conŃine faza 9
• exploatarea şi întreŃinerea sistemului conŃine faza 10
• dezvoltarea sistemului conŃine faza 17
1. Elaborarea temei de realizare

(Strategia de planificare a proiectului)
6. Exploatarea, întreŃinerea şi 2. Studiul şi analiza sistemului

dezvoltarea sistemului informatic existent
5. Implementarea sistemului 3. Proiectarea sistemului

informatic informatic
4. Realizarea sistemului informatic
Figura 1.11 Ciclul de viaŃă al unui sistem informatic

În dezvoltarea şi perfecŃionarea ştiinŃei conducerii unui suport deosebit l-a adus
informatica, care astăzi a devenit cel mai important instrument de investigare şi cunoaştere
ştiinŃifică a fenomenelor şi proceselor de mare complexitate, ce se desfăşoară în societate
îndeosebi în domeniul economic.
Informatica are o producŃie proprie specifică, ce e legată de prelucrarea automată a
datelor, folosind în acest scop mijloace de muncă şi tehnologii adecvate.
Această producŃie se subdivide în:
• proiectarea şi realizarea de sisteme informatice noi sau perfecŃionarea celor
existente
• prelucrarea automată a datelor, având ca scop obŃinerea informaŃiilor necesare
activităŃii de conducere şi de execuŃie din unităŃile economice
Principalele mijloace de muncă folosite de informatică sunt:
• calculatoarele electronice de orice tip
• unităŃile periferice corespunzătoare
• programele sau pachetelor de programe cu ajutorul cărora se asigură facilitatea
necesară a echipamentelor fizice
Obiectul muncii în informatică are caracter informaŃional, este înregistrat pe un suport
fizic specific sub formă de date pentru producŃia de prelucrare automată şi programe, reguli,
proceduri de utilizare şi exploatare, pentru lucrările de proiectare şi realizare de sisteme
informatice.
Obiectivele principale ale sistemelor informatice economice constau în creşterea
operativităŃii în informarea conducerii şi luarea deciziilor la toate nivelurile, creşterea
eficienŃei economice în toate domeniile de activitate, reducerea volumului documentelor şi
45
corespondenŃei scrise, utilizarea eficientă a personalului cu înaltă calificare prin eliberarea sa

de activităŃile de rutină.
1.8.4. Rolul sistemelor informatice în conducerea organizaŃiilor economice

Remarcăm faptul că în condiŃiile create de Internet, sistemul informatic se detaşează
de firmă şi chiar iese din cadrul ei făcând legătura directă cu băncile, cu furnizorii şi oferă
conducerii date despre mişcările pe care le execută concurenŃa. Conducerea firmei moderne
nu se mai mulŃumeşte cu o informare operativă ci doreşte prognoze, doreşte să prevadă
viitoarele mişcări ale concurenŃei şi viitoarea evoluŃie a pieŃei Ńinând cont de ceea ce se
petrece în prezent. De aceea chiar dacă nu proiectăm sisteme suport de decizie sistemele
informatice moderne trebuie să iasă din perimetru firmei.
1.9. EvoluŃia metodelor de abordare a sistemelor informaŃionale

Conceptele: obiect, clasă de obiecte, etc., au semnificaŃie diferită după opinia
diverşilor autori. Forma incipientă apare în anii 50-60 şi este numită program inteligibil, apoi
ajungându-se la modularizarea programelor.
După care au apărut modele orientate pe funcŃii, iar apoi a apărut modelul orientat pe
obiect.
Sinteza acestei evoluŃii a metodelor de abordare ar fi [22]:
• metode timpurii şi nesistematizate
• metode orientate pe ieşiri
• metode orientate pe procese, prin alegerea diagramelor de flux
• metode orientate pe date, cu diagramele entitate relaŃie
• metoda orientată pe obiecte.
O clasificare mai sumară ar putea fi [22]:
• metode orientate pe funcŃii de date
• metode orientate pe obiect
O altă clasificare ar fi cea pe generaŃii, anume [22]:
• generaŃia I a anilor 70, ce face analiza şi descompunerea ierarhică, numită
metoda carteziană
• generaŃia II a anilor 80 ce face analiza şi reprezentarea orientată sistematic
• generaŃia anilor 90 ce face analiza şi proiectarea orientată pe obiect
În urma celor prezentate mai sus putem concluziona:
• drumul spre metodele orientate pe obiect este destul de sinuos, cu o
multitudine de puncte de vedere
• unanimitatea categorisirii metodelor au stat la baza conceperii este imposibil
de prezentat, dar unele pot fi sintetizate
Majoritatea auturilor le grupează astfel [22]:
• metode orientate pe funcŃii sau metode de descompunere funcŃională
• metode orientate spre fluxuri de date, orientate spre procese, numite metode
orientate pe date
• metode orientate spre informaŃii sau date
• metode orientate pe obiecte
46
EvoluŃia metodelor de abordare a sistemelor informaŃionale
1.9.1. Caracteristicile metodelor de abordare a sistemelor

Aceasta este posibilă prin abordarea cu trei perspective specifice sistemelor sau prin
trei dimensiuni, astfel: date, funcŃii şi comportament.
Datele sunt surprinse prin prisma structuri lor sub formă de atribute, deci sistemul
stochează şi poate reaminti oricând fenomenele sau procesele studiate.
FuncŃiile scot în evidenŃă limitat ce face sistemul. Ele pot fi văzute ca procese,
deoarece elementele sistemului despre care se păstrează datele de rigoare sunt supuse unor
transformări funcŃionale prin intermediul proceselor.
Comportamentul este invocat pentru reda o altă modalitate de protecŃie a sistemului,
deci reliefează influenŃa evenimentelor, lucru ce ne sugerează dinamica sa.
Se poate vorbi de cubul ce dimensionează starea adevărată a unui sistem
informaŃional, unde muchiile sale arată cele trei dimensiuni, conform figurii 1.12.
Date
Adevărată
Comportament
FuncŃii
Figura 1.12 Starea unui sistem [24]
În majoritate, specialiştii din domeniu consideră că majoritate metodelor se bazează

pe:
• funcŃii sau descompunere funcŃională
• procesele (fluxuri de date), informaŃii (date) şi obiecte
1.9.2. Metoda descompunerii funcŃionale

Aceste concepte au fost introduse prima dată în programarea structurală de Dahl în
anul 1972, apoi în proiectare şi după aceea în analiză. Descompunerea funcŃională (DF) este
considerată ca o sumă de funcŃii, subfuncŃii şi interfeŃe funcŃionale sub formă de ecuaŃie,
astfel:
Descompunere FuncŃională = FuncŃii + SubfuncŃie + InterfeŃele funcŃiilor.
Această metodă are trei mari avantaje:

• simplitatea, ce este calea de rezolvare a problemei
• obŃinerea lejeră a cerinŃelor beneficiarului
• generarea de soluŃii pe diferite niveluri de abstractizare (sistem, subsistem,
funcŃie, subfuncŃie).
Ea are şi următoarele dezavantaje:
• concentrarea eforturilor spre funcŃii conduce la culegerea multor date
redundante;
• inexistenŃa unor reguli precise de descompunere;
• evidenŃa anevoioasă a interacŃiunilor non-ierarhice din sistemele complexe.
47
1.9.3. Metoda fluxurilor de date

Poate fi descrisă ca analiză structurală, care are următoarea ecuaŃie:
Metoda fluxului de date = Flux de date +Transformări date + Stocare date +

Terminatori + SpecificaŃii de proces + DicŃionarul datelor.
Ea permite analiştilor efectuarea reprezentării lumii reale prin linii ale fluxurilor de
date şi prin cerculeŃe pentru procese. Aceasta defineşte clar evenimentele din lumea reală, la
care sistemul trebuie să răspundă, fiind o formă embrionară a actualelor interacŃiuni dintre
utilizator şi sistem, care sunt bazate pe mesaje. Cu o documentaŃie specială suplimentară ce
include fluxurile datelor şi transferările lor la nivel inferior, cu ajutorul dicŃionarului de date,
respectiv al specificaŃiilor proceselor.
1.9.4. Metoda orientată spre informaŃii

Ea are ca obiect un simbol prin care se reprezintă una sau mai multe cazuri ale
entităŃilor lumii reale.
Aceasta are următoarea ecuaŃie:
Modelarea informaŃiilor = Obiecte + Atribute + RelaŃii + Supertipuri/subtipuri +

Obiectele asociate.
Această metodă are la bază două strategii:

Strategia veche ce are la bază conceperea listei atributelor, gruparea lor în obiecte,
stabilirea relaŃiilor între cazuri, folosirea supertipurilor/subtipurilor pentru extragerea
atributelor comune şi definirea obiectelor asociative pentru referirea relaŃiilor.
Strategia nouă ce este apropiată de anterioara, cu excepŃia primului pas, care prima
dată identifică obiectele lumii reale după care le descrie cu ajutorul atributelor.
1.9.5. Metoda orientată pe obiect

Această sintagmă “orientat pe obiect” este greu de definit, datorită diverselor
accepŃiuni ale specialiştilor din acest domeniu. Informatica are trei variante, anume: una
folosită la modelarea informaŃiilor, alta în programare şi alta în proiectarea sistemelor
informatice. Ea are următoarea ecuaŃie:
Orientat pe obiect = Clase şi obiecte + Moştenire + ComunicaŃie prin mesaje
NoŃiunile de obiect şi clasă sunt independente, obiectul aparŃine unei clase, iar clasa
este o grupare logică a obiectelor ce au aceeaşi structură şi comportament.
Obiectul fiind abstractizarea datelor elementare şi are ecuaŃia:
Obiect = Identitate + Comportament + Stare
Identitatea sa se realizează printr-un identificator al obiectului, care este atributul

invariabil şi care permite obiectului să fie adresat.
Comportamentul obiectului se defineşte printr-un set de operaŃiuni ce-i pot fi aplicate
şi se descrie în clasa căreia îi aparŃine.
Starea sa, este o valoare ce poate fi simplă sau structurată. Structurata se compune din
valori simple, referinŃe la obiecte sau valori care pot fi structuri.
48
Managementul proiectelor informatice
Concluzionăm, obiectul este o abstractizare a datelor elementare, caracterizată

printr-un identificator unic invariabil, o clasă căreia îi aparŃine şi o stare reprezentată printr-
o valoare simplă sau structurată.
1.10. Managementul proiectelor informatice
1.10.1. Aspecte definitorii şi organizatorice

Managementul proiectelor1 este o strategie managerială aplicată mai ales în proiecte
de informatizări şi investiŃii de altă natură. Ea presupune constituirea unor echipe de
specialişti în analiza, proiectarea şi implementarea de aplicaŃii informatice şi implicarea de
specialişti din diferite compartimente funcŃionale, mai ales de contabilitate, comercial şi de
management a resurselor umane. Echipele de proiect au ca obiectiv lansarea şi realizarea
proiectului cu respectarea specificaŃiilor tehnice, a termenelor de execuŃie şi a bugetului de
cheltuieli. ExistenŃa şi funcŃionarea unor astfel de echipe implică două probleme
organizatorice importante: integrarea echipei de proiect în structura organizatorică a firmei
(de investiŃii) şi crearea unei structuri organizatorice pentru proiectul în sine.
În structura organizatorică funcŃională a societăŃilor comerciale integrarea acestei
metode de management se realizează prin integrarea proiectului în organizarea funcŃională a
firmei. Managementul proiectului este subordonat compartimentului funcŃional, de regulă, de
contabilitate, care poate avea rolul cel mai important în implementarea lui.
Aşa cum am menŃionat la analiza structurilor manageriale şi de control, managementul
prin proiecte conferă multiple atuuri de finalizare eficientă a unor obiective importante ale
societăŃilor comerciale, cum este cel al informatizărilor, dar implică şi capcane, cum este cea
a perturbării sistemului de reglare existent înainte de implementarea noii structuri.
FaŃă de organizarea funcŃională clasică, organigrama unei societăŃi comerciale în care
se implementează managementul prin proiecte se poate prezenta ca în figura 1.11, care
reflectă “organizarea pe proiecte pură”. În cadrul fiecărui proiect (de analize conjucturale,
oferta de produse, tehnologii de producŃie, de informatizare etc.), managerul are autoritate şi
responsabilitate deplină. Un proiect constituie o entitate autonomă distinctivă în cadrul
structuri firmei, cu propriul său personal tehnic, propria administraŃie, “relaŃionată” de
organizarea de ansamblu (doar) prin rapoartele periodice pe care managerul de proiect trebuie
să le prezinte conducerii strategico – tactice. Unele societăŃi comerciale prevăd proceduri
foarte detaliate în ceea ce priveşte administrarea, finanŃele, personalul şi controlul în cadrul
proiectului, în timp ce altele acordă o libertate mai mare sau mai redusă în acest sens. În
ultima instanŃă, combinaŃia clasic – modern este dependentă de mărimea şi perspectivele
organizaŃiei, de cerinŃele şi posibilităŃile existente.
Avantaje:
1. Centralizarea resurselor similare.
2. Disponibilitatea forŃei de muncă.
3. Stabilitate mare.
4. Standarde profesionale înalte.
5. Asigură o flexibilitate maximă în utilizarea personalului. ExperŃii pot fi implicaŃi
temporar în proiect, apoi retrimişi la munca lor obişnuită.
6. ExperŃii pot fi utilizaŃi în cadrul mai multor proiecte.
7. Specialiştii implicaŃi în cadrul proiectului pot apela la colegii lor din cadrul
compartimentului funcŃional din care provin pentru a face schimburi de cunoştinŃe şi
1
www.ase.ro/teza_capitol.pdf
49
experienŃă, ceea ce poate constitui o sursă de soluŃii creative şi sinergice pentru problemele
proiectului.
8. Posibilitatea asimilării unor noi tehnologii performante.
9. Permite utilizarea în cadrul proiectului a aceloraşi proceduri tehnice şi manageriale
folosite şi la nivelul firmei.
10. Specializare în cadrul funcŃiilor.
11. MenŃine parcursurile normale de evoluŃie în carieră din cadrul organizaŃiei.
Dezavantaje:
1. Număr mare de niveluri ierarhice.
2. Lipsa unei “vederi” de ansamblu a proiectului pentru majoritatea personalului
implicat.
3. Clientul nu este în centrul preocupărilor. Unitatea funcŃională căreia îi este
subordonat proiectul are propriile sale sarcini de realizat şi acestea prevalează de obicei faŃă
de cele ale proiectului.
4. Unitatea funcŃională tinde să fie orientată către realizarea şi controlul activităŃile
tehnice şi nu către problemele globale ale proiectului.
5. Nu i se acordă unei singure persoane întreaga responsabilitate pentru proiect.
6. MotivaŃia echipei de proiect este slabă deoarece proiectul este perceput ca un aspect
marginal în cadrul activităŃii firmei.
7. Poate favoriza apariŃia rivalităŃii şi competiŃiei neloiale între echipele de proiect în
lupta acestora pentru acces la resursele organizaŃiei.
8. Succesul este totdeauna însuşit, iar eşecul nu aparŃine nimănui.
9. RezistenŃă în faŃa schimbării.
10. Proces lent de luare a deciziei.
Adunarea Generală a AcŃionarilor
Cominsia de Cenzori
Consiliul de adminstraŃie
Director General
COMPORTAMENTE MANAGER PROIECT MANAGER PROIECT MANAGER PROIECT

COMUNE A B C
• Resurse
Umane
• Contabilitate
• Financiar
Administrare Contract
Administrare Contract
•
Administrare Contact
Contactare
Resurse Contract
Umane
•
Resurse Umane
Aprovizionare
Juridice
Aprovizionare
Contabilitate
Contabilitate
Aprovizinare
Contabilitate
•
ProducŃie
ProducŃie
informatică
ProducŃie
Resurse
Figura 1.13 Organigrama pentru managementul prin proiecte
50
Într-o concepŃie modernă, aplicabilă în “întreprinderi inteligente”, racordate la

internet, managementul prin proiecte este asociabil cu organizarea matricială. “Nodurile”
structurii pot reprezenta centre de decizie, formate din specialiştii antrenaŃi în rezolvarea
problematicii aflate la intersecŃia linie (manager proiect) – coloană (specialişti de marketing,
ingineri, contabili etc.).
Având în vedere avantajele şi dezavantajele specifice fiecărei forme de organizare, se
poate opta pentru o combinaŃie de structuri, având în vedere condiŃiile specifice fiecărei
firme. Managementul şi marketingul informatizate se realizează prin integrarea orizontală
(funcŃională) şi verticală (ierarhică) de aplicaŃii, ca proiecte finale executabile, menite a
facilita exercitarea funcŃiilor întreprinderii şi ale conducerii. Rezultă sisteme informatice de
gestiune şi de asistare a deciziilor de tratare şi folosire optimală a informaŃiei economico -
financiare şi cu caracter social. Datele şi cunoştinŃele din colecŃii pot fi organizate în fişiere
independente (relative la o anumită problemă), în fişiere integrate, în baze de date centralizate
sau distribuite (în reŃele de calculatoare). Corespunzător modului de organizare a datelor,
aplicaŃiile informatice pot fi: independente; integrate care comunică direct (on-line, în timp
real) sau indirect (off - line) în soluŃionarea problemelor complexe. Exploatarea unui sistem
(aplicaŃii) informatic(e) se poate face centralizat sau cu distribuire parŃială sau totală, în
funcŃie de posibilităŃile sistemelor de calcul disponibile şi concepŃia de ansamblu prestabilită.
În esenŃă, managementul prin proiecte presupune numirea unui manager general al
proiectului de finalizare a unui obiectiv important (automatizare, proiectarea şi lansarea de
produse noi, realizarea unor retehnologizări etc.) care devine răspunzător de organizarea şi
desfăşurarea acŃiunilor din faza de lansare a proiectului şi până la finalizarea lui. Managerul
îşi alege echipa (subordonaŃii) şi colaboratorii în funcŃie de condiŃiile specifice ale
organizaŃiei sau a organizaŃiilor în care urmează să fie realizată finalizarea acŃiunilor de
implementare a proiectului.
1.10.2. Metodologii de management ale proiectării
1.10.2.1. Managementul afacerii şi tehnologia informaŃiei

Astăzi, mai mult ca niciodată, desfăşurarea oricărei activităŃi economice, financiare
sau bancare nu se poate imagina fără utilizarea unui puternic suport informaŃional care să
asigure avantajul concurenŃial în raport cu ceilalŃi competitori de pe piaŃă. A dobândi
cunoaştere prin informaŃia obŃinută este rolul tehnologiei informaŃiei (TI).
TI înseamnă hardware, software, comunicaŃii, reŃele, baze de date, automatizarea
lucrărilor de birou precum şi toate celelalte echipamente şi componente software necesare
prelucrării informaŃiei.
TI oferă astăzi nu doar suportul informaŃional necesar desfăşurării afacerii în condiŃii
de eficienŃă ci şi soluŃii pentru regândirea modului de a-Ńi organiza afacerea cu scopul
menŃinerii competitivităŃii.
Reingineria afacerilor. Reengineering înseamnă regândirea fundamentală şi
reproiectarea radicală a proceselor afacerii pentru obŃinerea de îmbunătăŃiri substanŃiale
privind costurile,calitatea, viteza de reacŃie a decidenŃilor (Mihail Hammer). Această
regândire a modului de a face afaceri este influenŃată şi găseşte totodată răspunsuri în noile
soluŃii TI. Modul de desfăşurare a afacerii în cadrul oricărei firme se schimbă (figura
următoare) ca urmare a acŃiunii conjugate a următorilor factori (lista acestora rămâne
deschisă) [27]:
• Globalizare
• CompetiŃie de nivel înalt
• InformaŃia devenită resursă cheie
51
• SpaŃiul virtual de muncă şi chiar derularea activităŃii în condiŃiile companiei

virtuale
• ComerŃ electronic
• ExistenŃa în cadrul firmei a personalului specializat în procesarea datelor şi
analiză
• (knowledge worker)
• Un nou tip de relaŃie cu banca prin care se obŃin servicii şi produse noi ca
urmare a promovării noilor soluŃii TI etc.
Knowledge Globalizare
worker
competiŃie
ComerŃ Noua viziune
electronic asupra modului
de desfăşurare a InformaŃia resursă cheie
afacerii
Un nou tip de relaŃie

SpaŃiul de muncă
cu banca
virtual
Figura 1.14 Noua viziune asupra modului de desfăşurare a afacerii [23]
Impactul TI asupra firmei nu se resimte doar din mediul exterior ci şi din interiorul
firmei. Orice organizaŃie (firmă, bancă etc.) presupune existenŃa a cinci elemente
(componente) interdependente (vezi figura de mai jos):
• Structura organizatorică
• Managementul şi procesele afacerii
• Tehnologia informaŃiei
• Strategia organizaŃiei
• AngajaŃii şi cultura organizaŃiei
Aceste componente trebuie să se găsească într-o stare de echilibru şi această stare se va
menŃine atât timp cât nu se produc schimbări semnificative în mediul extern sau în oricare dintre
componente. Componenta TI cunoaşte o dinamică deosebită. Acest lucru determină mutaŃii
calitative asupra celorlalte componente. Dinamica componentei TI se resimte şi la nivelul
strategiei organizaŃiei oferind mijloace şi instrumente specifice analizei şi fundamentării strategiei.
• Planificare şi control la
nivelul întregii firme
• Elaborarea strategiei firmei
M. strategic
• Planificare şi controlul la
nivelul subunităŃilor
Management tactic organizatorice
• Planificarea şi controlul
Management operaŃional operaŃiilor zilnice
Figura 1.15 Sistem informatic al unei firme [21]
52
Sistemul informatic al firmei trebuie să integreze subsisteme informatice acoperind

nevoile informaŃionale specifice fiecărui palier managerial, conform figurii anterioare.
1.10.2.1. Unele strategii de proiectare a sistemelor informatice

În urma cercetărilor efectuate şi a exigenŃei acumulate s-a ajuns la mai multe metode
şi metodologii de proiectare a sistemelor informatice, în dorinŃa scurtării duratei ciclului de
proiectare – realizare şi obŃinerea sistemelor de calitate superioară cu cheltuieli cât mai mici.
Strategiile ce se aplică în prezent, se pot clasifica în funcŃie de rolul sistemului informatic în
cadrul sistemului obiect şi de modalităŃile folosite la abordarea şi realizarea unui nou sistem.
Avem astfel clasificarea:
1. După rolul sistemului informatic în cadrul sistemului obiect se disting
următoarele strategii:
• Strategia ameliorativă – ce consideră că rolul principal al sistemului
informatic constă în îmbunătăŃirea performanŃelor proceselor informaŃionale
prin automatizarea activităŃilor şi operaŃiilor cu caracter repetitiv şi de rutină.
• Strategia inovatoare – care consideră că introducerea sistemului informatic
trebuie însoŃită de schimburi sau perfecŃionări importante în organizarea şi
funcŃionarea sistemului obiect.
• Strategia adoptivă – ce consideră că sistemul informatic urmează a fi
conceput şi realizat în aşa fel încât să se poată adapta şi evalua cât mai uşor
odată cu schimburile survenite în cerinŃele informaŃionale sau în organizarea şi
funcŃionarea sistemului obiect.
2. După modalitatea de abordare şi realizare a sistemelor informatice distingem:
• Strategia top-down (descendentă) – ce are la bază principiul descompunerii
unui sistem complex, pe nivele succesive de detaliere, până la obŃinerea unor
componente suficient de simple şi independente încât să poată fi abordate şi
dezvoltate separat.
• Strategia botton-up (ascendentă) – ce se bazează pe principiul definirii şi
asamblării complementar de nivel inferior în cadrul unui nivel superior, cu
precizarea că integrarea complementelor se face succesiv, pe măsură ce sunt
definitivate şi realizate efectiv.
3. După modul de parcurgere al etapelor ce compun ciclul de existenŃă a sistemelor
informatice, se disting:
• Strategia liniară sau în cascadă – ce presupune parcurgerea succesivă a
etapelor, cu posibilitatea revenirii la etapa imediat precedentă.
• Strategia prototipurilor – ce presupune elaborarea unei versiuni iniŃiale a
sistemului informatic cu caracter prototip, în care sunt incluse numai funcŃiile
de prelucrare esenŃiale sau critice.
• Strategia proiectării în doi paşi – care presupune parcurgerea fiecărei etape
până la elaborarea programelor, în doi paşi astfel: în primul pas se realizează
un studiu preliminar ce serveşte etapei imediat următoare, iar în caz contrar se
revine la etapa precedentă.
• Strategia documentării anticipate – ce presupune elaborarea cu anticipaŃie a
documentelor de utilizare a sistemului, chiar din fazele preliminare ale
proiectării.
Aplicarea în practică a acestor strategii este făcută după particularităŃile sistemului
informatic ce urmează să fie proiectat şi de condiŃiile de realizare oferite de unitatea
economică beneficiară.
53
1.10.2.2. Strategia clasică

Principalele etape de lucru şi specificaŃii de realizare a unui proiect informatic, în
concepŃia clasică, dedusă din experienŃa specialiştilor în analiza şi conceperea de sisteme
informatice, sunt:
1. elaborarea temei de realizare cu specificarea cerinŃelor şi a restricŃiilor sistemului,
ca potenŃială bază juridică de reglementare a raporturilor proiectant-beneficiar (utilizator);
2. proiectarea de ansamblu care, în general, este similară acŃiunilor de elaborare a unui
studiu tehnico-economic pentru investiŃii de natură industrială. Ea constă în a stabili, pe
coordonatele unui proiect director de informatizare, concepŃia globală a sistemului informatic,
structura acestuia, priorităŃile de realizare, necesităŃile şi posibilităŃile economico - financiare
ale utilizatorului, eficienŃa scontată. ImportanŃa etapei derivă din faptul că este ultima în care
analiza vizează ansamblul acŃiunilor de prefigurare nu numai a viitorului sistem informaŃional
- decizional, ci şi conexiunile acestuia;
3. proiectarea de detaliu sau tehnică a fiecărei componente de tip subsistem sau
aplicaŃie, prin conceperea, într-o manieră analitică, a tehnologiei tratării informaŃiei pe traseul
intrări – prelucrări - ieşiri, prin elaborarea algoritmilor de programare şi a specificaŃiilor de
programare şi exploatare viitoare a procedurilor tehnologiei. Un proiect tehnic rezultat trebuie
să aibă caracteristicile unui proiect elaborat pentru produse de natură industrială în care
desenele de execuŃie (specificaŃiile de realizare) şi fişele tehnologice (arborii de programare)
definesc tehnologiile şi reŃetele de fabricaŃie;
4. programarea fiecărei componente prin scrierea programelor într-un mediu adecvat,
testarea şi integrarea lor în mediul pentru care au fost concepute;
5. testarea procedurilor cu date reale în vederea omologării şi acceptării lor de către
beneficiar, implementarea lor în cadrul sistemului informatic (informaŃional);
6. exploatarea şi întreŃinerea produsului informatic rezultat, urmărind prin aceasta,
îmbunătăŃirea performanŃelor acestuia.
În fiecare etapă se elaborează documentaŃii specifice, iar spre final, se completează şi
definitivează documentaŃia de prezentare, operare şi întreŃinere a produselor informatice nou
create.
Studierea realizărilor practice ale informaticii aplicate scot în evidenŃă faptul că, în
scopul asigurării unei independenŃe relative, un sistem informatic se structurează (în general)
funcŃional, urmărind asigurarea condiŃiilor pentru exercitarea funcŃiilor sistemului de reglare.
Astfel, într-o întreprindere, subsistemele informatice sunt: de marketing, de cercetare -
dezvoltare, de producŃie, comercial, financiar – contabil şi de personal. Pe domenii de
activităŃi sau compartimente, un subsistem se detaliază în aplicaŃii (unităŃi funcŃionale), iar o
aplicaŃie în proceduri automate şi de interfaŃă, ca unităŃi de prelucrare prin care managerii şi
executanŃii să poată obŃine informaŃiile dorite.
Eforturile analiştilor / proiectanŃilor de sistem s-au concentrat, adeseori, spre creşterea
gradului de organizare şi raŃionalizare a sistemelor informaŃionale din societăŃi comerciale, cu
toate că multe realizări s-au concentrat mai mult asupra transpunerii unor proceduri şi lucrări
manuale în proceduri automatizate. IneficienŃa unor sisteme sau programe informatice s-a
datorat, de multe ori, nu proiectanŃilor, ci modului în care beneficiarii de informaŃii au
colaborat în organizarea acŃiunilor şi i-au ajutat pe informaticieni să definească corect
cerinŃele şi restricŃiile tratării informaŃiei.
1.10.2.3. Strategia prototipizării

ExistenŃa unor probleme similare pentru unităŃi economico-sociale cu acelaşi profil al
activităŃilor, prioritatea automatizării unor funcŃii vitale ale unor organizaŃii, au stat la baza
prototipizării realizărilor informatice.
54
Scopul vizat prin aplicarea strategiei prototipizării este structurarea procesului de

realizare a unui produs informatic necesar automatizării funcŃiilor critice ale unei societăŃi
comerciale (cum ar fi funcŃia de producŃie / managementul execuŃiei) sau standardizarea şi
tipizarea sistemelor informatice pe tipuri de organizaŃii.
Un prototip este un model al comportării produsului dorit care se realizează relativ
repede cu cheltuieli mici şi timp scurt de finalizare. Folosind prototipul, utilizatorul poate
aprecia soluŃiile preconizate de proiectant prin prisma realismului şi a completitudinii lor. În
acest mod, utilizatorii îsi clarifică cerinŃele informaŃional - decizionale proprii filtrându-le şi
selectând soluŃiile de produs informatic cele mai eficace în desfăşurarea activităŃilor specifice.
Pe baza experienŃei dobândite, prototipurile parŃiale se convertesc în produs final prin
îmbunătăŃirea funcŃiilor lor. Metamorfoza se realizează prin dezvoltarea iterativă a
prototipului mai reprezentativ (pilot) adăugând noi caracteristici funcŃionale produsului care
răspund cerinŃelor de informare, performanŃe şi calitate ale realizărilor informatice.
O astfel de concepŃie se apropie de condiŃiile proiectării produselor şi a tehnologiilor
industriale prin care se asigură nu numai tratarea informaŃiei pentru gestiunea economico -
financiară a societăŃilor comerciale, ci şi asistarea procesului de luare a deciziilor aplicând
politici manageriale moderne, cum sunt: managementul prin obiective, managementul prin
excepŃii, managementul prin rezultate etc.
De altfel, prototipizarea stă la baza noului mod de utilizare a mediilor de programare
vizuale, bazat pe asistenŃi specializaŃi care oferă instrumente de lucru complexe şi pe
„vrăjitori” care predefinesc structurile de date şi paşii de lucru în gestionarea informaŃiilor.
1.10.2.4. Strategii orientate obiect

CerinŃele stocării unor cantităŃi tot mai mari de informaŃii, dezvoltarea mediilor de
programare care pot surprinde şi dinamica unei organizaŃii, orientarea automatizărilor spre
realizări multimedia de integrări texte – imagini - sunete în convergenŃa sistemelor
informatice spre sisteme expert de inginerie a cunoaşterii au dus la apariŃia şi dezvoltarea
strategiilor orientate obiect.
În modelarea specifică acestei strategii, un obiect al lumi reale are o triplă abordare:
este "văzut" ca actor autonom ce răspunde la mesaje ceea ce permite simularea de procese
paralele; în rolul de concept specific, obiectul asigură modelarea cunoştinŃelor înglobând, pe
lângă date, semnificaŃii ale datelor (semantica informaŃiei, cunoştinŃe şi fapte asupra unor
metodologii şi activităŃi); ca şi "cutie neagră" modelul asigură condiŃii de acŃionare asupra lui
modularizat şi să fie exploatat prin dialoguri sugestive. Aceste abordări creează condiŃii ca un
obiect să aibă o triplă reprezentare: structurală, ca o realizare (instanŃierea) a unui tip de dată,
caracterizată printr-o structură ascunsă prin operaŃii; conceptuală pentru entităŃile lumii reale
care pot fi specializate şi dinamică pentru actori la care obiectul este autonom şi activ
răspunzând la mesaje.
EsenŃa abordării orientată - obiect este definirea caracteristicilor obiectelor dintr-o
aplicaŃie şi realizarea interacŃiunii lor prin schimbul de mesaje. Xavier Castellani consideră
că metodologia şi concepŃia orientate obiect introduc2: conceptul de serviciu în loc de
operaŃie; noŃiunea de cunoştinŃă şi conceptul de transmutaŃie privind transformările
obiectului. Aplicarea metodologiei presupune: metode de analiză şi concepŃie a sistemului de
obiecte (date/prelucrări independente şi modele asociate de tip entitate – atribut - relaŃie);
modelul conceptual al utilizatorului răspunzând la întrebări de genul "ce?", "când?"; modelul
detaliat (operaŃional) optimizat; nivelul logico-organizatoric de răspuns la cerinŃe de tipul
2
.Xavier C.-Methodologie generale d'analyse et de conception de systemes d'objets, Mason,
Paris, 1993.
55
"unde?", "cu ce?", "când?"; nivelul fizic de răspuns la întrebarea "cum se rezolvă
problemele?".
În abordarea Orientată Obiect (OO), un program devine un ansamblu de obiecte care
schimbă mesaje generatoare de operaŃii sau metode de transformare a stării lor interne şi de
restituire a valorii unor parametrii. O bază de date - obiect conŃine obiectele programelor de
aplicaŃii. Un obiect oarecare este persistent prin aceea că durata sa de viaŃă este superioară
programului care la creat.
Prin proiectarea unui obiect, acestuia i se asociază o structură (atribute, câmpuri
aparŃinătoare) şi funcŃionalitatea sa redată prin proceduri şi funcŃii proprii clasei de obiecte. În
acest fel, obiectele înglobează structuri de date şi comportamente (operaŃii, metode).
În abordarea clasică descompunerea unui sistem este funcŃională, procedurală; pentru
abordarea OO devine esenŃială înŃelegerea sistemului prin prisma descompunerii lui în
entităŃi – obiecte şi al stabilirii relaŃiilor între obiecte devenind esenŃială diagrama sau
diagramele obiectului prin care se răspunde la întrebări de tipul "cine face?", "care sunt
relaŃiile între cei ce fac?", "ce este sistemul?".
Indiferent de strategia aplicată, pentru conceperea şi exploatarea de produse
informatice performante un factor esenŃial al reuşitei acŃiunilor îl reprezintă strânsa colaborare
proiectant - utilizatori prin instrumente de lucru simple şi sugestive.
Un astfel de instrument îl poate constitui tehnica diagramelor aplicată în succesiunea:
diagrame orizontale de flux informaŃional - decizional pentru cunoaşterea situaŃiei existente şi
prefigurarea noului sistem în perspectiva informatizării stabilind: modificările de flux şi
necesarul de fişiere permanente şi tranzacŃionale; scheme (organigrame) de sistem de
reprezentare a principalelor proceduri de creare şi gestionare a fişierelor; arbori de programare
pentru meniurile de integrare a prelucrărilor; arbori de programare pentru procedurile
meniului de prelucrare a fişierelor şi de răspuns la cererile de informare.
1.10.3. Organizarea echipelor de analiză şi proiectare a activităŃilor

Din experienŃa practică a realizării tehnologiilor informaŃionale, bazate pe
automatizări, s-au desprins, ca tehnici organizatorice3: (1) echipa programatorului-şef; (2)
echipa programatorului - şef revizuită; (3) echipa chirurgicală; (4) organizarea democratică a
programării, (5) echipe organizaŃionale.
1) Echipa proiectantului / programatorului-şef.
Scopurile urmărite în definirea, organizarea şi desfăşurarea acŃiunilor sunt:
• structurarea procesului de realizare a sistemului informaŃional – decizional
automatizat în vederea diversificării activităŃilor realizate de specialişti
• asigurarea unui mediu de lucru care să favorizeze utilizarea eficientă a
instrumentelor proiectării asistate de calculator de tipul generatoarelor (de
formulare, de rapoarte, pentru ecrane etc.), a „asistenŃilor” specializaŃi (pentru
folosirea butoanelor, a listelor, a casetelor de dialog etc.) şi a „scurtăturilor”
sau a „vrăjitorilor” pentru folosirea unor componente predefinite prin
macrocomenzi ale mediilor de programare
• asigurarea "vizibilităŃii" proiectului, a produsului informatic pe întreg ciclul de
realizare fie ca prototip, fie ca o versiune intermediară de dialog cu utilizatorii ;
• prevederea unor modalităŃi de instruire a echipei dezvoltând metode şi tehnici
noi de lucru, cum sunt instrumentele proiectări asistate şi de analize directe
(on-line) ale proceselor de finalizare a acŃiunilor
3
D.Oprean,M.R.Abdel- TI&C: Proiectarea de tehnologii informaŃional-decizionale, Ed. Risoprint, Cluj-Napoca,
2001, pag. 17-19
56
• cunoaşterea foarte bună a evoluŃiei proceselor tehnologice de către cel puŃin

doi membri ai echipei
• În îndeplinirea scopurilor, regulile de constituire şi funcŃionare a echipei sunt:
o definirea clară a funcŃiei fiecărui component al echipei şi a relaŃiilor
dintre membrii ei
o existenŃa unui conducător tehnic permanent, ca şef de proiect, în
persoana proiectantului sau a programatorului - şef
o facilitarea controlului administrativ, inclusiv privind consumurile şi
cheltuielile angajate în finalizarea proiectului
o simplificarea comunicării cu echipele externe şi alegerea unui limbaj
adecvat de comunicare (cum ar fi, spre exemplu, diagramele de flux
informaŃional, descrierile în pseudocod sau tabelele de decizii şi
organigramele)
o evitarea situaŃiilor de impas în luarea deciziilor
o repartizarea sarcinilor pentru fiecare membru al echipei pe baza
definirii riguroase a responsabilităŃilor
o informarea periodică asupra stadiului de realizare a produsului
informatic
o evaluarea lejeră a efortului depus de membri
• disciplina riguroasă în proiectarea, programarea şi implementarea proiectului
Echipa este alcătuită , în principal, din proiectantul (programatorul) - şef, proiectantul
/ programatorul - verificator (locŃiitor), secretar şi proiectanŃi / programatori. Ea este direct
răspunzătoare pentru realizarea proiectării tehnice (de detaliu), a programării şi a integrării
proiectelor / produselor informatice.
2) Echipa proiectantului / programatorului-şef revizuită.
Împrumutând avantajele altor tehnici, principalele obiective vizate în echipa
proiectantului / programatorului-şef revizuită sunt:
• disciplinarea muncii ca şi în cazul echipei proiectantului/programatorului-şef
• specializarea pe funcŃii, cum se procedează în cadrul echipelor chirurgicale
• partajarea sarcinilor între membrii echipei, ca şi în cazul organizării
democratice a programării
Aceste obiective fac ca tehnica să aibă un caracter integrator al celorlalte tehnici
organizaŃionale ceea ce implică necesitatea ca managerul de proiect să aibă responsabilitate şi
autoritate în conducerea echipei, fără ca aceasta să impună neapărat şi posedarea unor calităŃi
de super - specialist (programator), aşa cum impune tehnica proiectantului / programatorului -
şef.
Aplicarea acestei tehnici presupune:
• formalizarea organizării procesului de realizare prin definirea clară şi coerentă
a sarcinilor de execuŃie tehnologică pe membri ai echipei
• stabilirea legăturilor de comunicare dintre echipa de conducere - utilizatori şi
echipa de integrare şi întreŃinere a proiectului/produsului informatic
• crearea unui mediu de lucru deschis în procesul aplicării tehnologiei
informaŃionale şi de comunicare
• verificarea produselor intermediare şi accentuarea controlului pe stadii de
realizare
• evitarea dependenŃei procesului de realizare a produsului în ansamblul său de
realizările individuale
Echipa este constituită din managerul de proiect, locŃiitor, persoana care asigură
legătura cu utilizatorii, administratorul proiectului şi proiectanŃi / programatori. OpŃional, din
echipă face parte şi un editor specializat în elaborarea de documentaŃii. Echipa se poate diviza
57
în colective pentru proiectarea de tehnologii şi produse informatice şi pentru codificarea -

testarea de produse, astfel încât să se furnizeze soluŃia organizatorică la nivelul întregului
ciclu de realizare a sistemului. Prin modul de definire şi de aplicare, tehnica echipei
proiectantului / programatorului-şef revizuită îmbină conducerea administrativă cu cea
tehnologică.
3) Echipa chirurgicală.
Echipa este alcătuită din specialişti de înaltă clasă, sprijiniŃi în munca lor de un
administrator, un editor şi unul sau doi secretari. Fiecare specialist are un nume în
concordanŃă cu funcŃia deŃinută în echipă: instrumentist, grafician, „căpitan”, testator,
specialist în limbaj, specialist în comunicaŃii etc. Tehnica îşi propune:
• definirea clară a responsabilităŃilor profesionale pe componenŃi ai echipei
• recunoaşterea fiecărui membru al echipei ca un expert în domeniu
• recunoaşterea importanŃei legăturilor de comunicare în echipă şi specializarea
lor completă şi consistentă
• asigurarea comunicării cu alte echipe printr-un membru, desemnat ca şi co-
pilot
• asigurarea unei documentaŃii de calitate (prin co-pilot)
Tehnica echipei chirurgicale se aplică în etapele de proiectare tehnică si programare.
Ea îmbină armonios sarcinile conducerii administrative cu cele de realizare a produsului,
creând un climat de responsabilitate a membrilor, o disciplină şi o manieră de lucru unitare.
4) Organizarea democratică a proiectări / programării.
În aplicarea tehnicii, principiile de lucru sunt:
• colaborarea democratică, de pe poziŃii de egalitate, între toŃi membrii echipei
• verificarea specificaŃiilor de realizare a fiecărui părŃi de proiect / produs-
program de către un membru al echipei, diferit de cel care le-a elaborat, înainte
de codificarea (programarea) produsului
• partajarea efortului de programare între toŃi membrii echipei, în vederea
depistării la timp a eventualelor erori
• folosirea unor metode de lucru unitare care să faciliteze comunicarea
• ridicarea continuă a nivelului de pregătire a echipei prin învăŃarea de noi
metode, tehnici şi algoritmi de soluŃionare a problematicii
• rotaŃia membrilor la conducerea echipei
Echipa este alcătuită dintr-un număr restrâns de membri. Tehnica se aplică la
proiectarea, codificarea şi testarea programelor, necesare finalizării proiectelor. Ca
dezavantaj, se remarcă dificultatea de a defini clar sarcinile fiecărui membru în cadrul
echipei; de asemenea, în aplicarea tehnicii apar dificultăŃi în comunicarea cu alte echipe şi pot
interveni controverse între membrii echipei datorită lipsei unui responsabil permanent.
5) Echipe organizaŃionale4.
Echipele organizaŃionale îşi propun:
• noi dimensiuni tehnico-economice ale comunicării, cum sunt: eliminarea
barierelor de comunicare temporale şi spaŃiale, practici flexibile de muncă,
sporirea productivităŃii capitalurilor investite, în special a celui uman prin
managementul bazat pe cunoştinŃe, creşterea responsabilităŃilor bazate pe
competenŃă şi autoritate, îmbunătăŃirea controlului execuŃiei sarcinilor,
flexibilitatea structurilor şi a tehnologiilor aplicate ş.a.
• sporirea culturii întreprinderii prin: identificare om - organizaŃie,
cooperare+solidaritate+colaborare, crearea unui climat de încredere şi
implicare, interes sporit în cunoaşterea şi promovarea obiectivelor organizaŃiei,
4
Fotache D.- Groupware-Metode, tehnici şi tehnologii pentru grupuri de lucru,Ed. Polirom, Iaşi, 2003
58
creşterea valorii muncii depuse de fiecare, a randamentului capitalului

imaterial etc.;
• asigurarea unui nou climat social prin: creşterea satisfacŃiei în muncă,
creşterea salariilor, reducerea izolării, posibilităŃi de instruire continuă, sănătate
şi siguranŃă în muncă mai bune, aplicarea principiilor ergonomice în muncă,
utilizarea mai eficientă a (sub)echipelor de lucru etc.
Realizarea dezideratelor de genul celor menŃionate presupune valorificarea strategiilor
şi a tacticilor organizaŃiei în contextul proiectării şi a reproiectării tehnologiilor de informare
şi comunicare informatizate. Ca şi consecinŃe ale utilizării echipelor de lucru, se remarcă:
valorificarea strategiilor organizaŃionale prin reproiectarea structurilor organizatorice (re-
engineering), formarea de echipe autonome de lucru şi acces imediat la informaŃii cu caracter
critic asupra sistemului; reducerea costurilor interne şi a timpilor de lucru, ameliorarea şi
diversificarea serviciilor către clienŃi ş.a. Din continua preocupare pentru specializare şi
performanŃe, rezultă agenŃi inteligenŃi, ca utilizatori eficienŃi ai inteligenŃei artificiale cu
caracteristicile: îşi adaptează comportamentul în funcŃie de caracteristicile mediului în care
funcŃionează, “memorează” experienŃa dobândită, se comportă ca un subsistem capabil de
înŃelegere, “îmbogăŃeşte” sistemul în care funcŃionează, utilizând funcŃii automatizate privind
tratarea informaŃiei etc. Astfel de agenŃi pot fi: sociabili care învaŃă “gusturile” utilizatorilor,
de căutare a informaŃiei dorite, pentru “navigări” în baza informaŃională după criterii utilitare,
ghizi ş.a.
Pentru programarea, organizarea şi controlul derulării lucrărilor de analiză, proiectare,
programare şi integrare a unui proiect sunt uzuale tehnicile şi metodele de coordonare
activităŃilor menŃionate (tehnica Gantt; metoda drumului critic; metoda PERT ş.a.).
Indiferent de metodele şi / sau tehnicile folosite, managementul prin proiecte poate fi
mijlocul de iniŃiere şi finalizare a unor proiecte viabile, eficace care să asigure realizarea unor
performanŃe superioare, benefice pentru proiectanŃi şi beneficiari.
1.10.4. Elaborarea specificaŃiilor de proiectare

În acŃiunile de informatizare a societăŃilor comerciale, managementul prin proiecte5
presupune ca, după stabilirea echipei de lucru, a acŃiunilor principale de exercitat şi a
calendarului (programului) de eşalonare a utilizării resurselor, să se realizeze proiectarea şi
programarea aplicaŃiilor informatice necesare automatizării proceselor informaŃional-decizionale.
De altfel, prin modul de concepere, un program informatic rezultat poate fi asimilat unui produs
de natură industrială a cărei concepere şi lansare în fabricaŃie trebuie precedate de proiectarea în
detaliu a produsului şi a tehnologiei specifice de realizare şi pregătirea condiŃiilor de producŃie.
Prin urmare, a realiza un proiect informatic, în esenŃă se, elaborarea specificaŃiilor de proiectare
tehnică a produsului informatic pe baza cărora urmează finalizarea acestuia prin acŃiunile de
scriere, testare şi integrare a programelor. Bazată pe rezultatele analizei contextului informatizării
şi a proiectării conceptuale de ansamblu, proiectarea tehnică presupune delimitarea şi
algoritmizarea prelucrărilor, în concordanŃă cu cerinŃele de informare şi de decizie. Un algoritm,
ca număr finit de operaŃii necesare realizării unei funcŃii, activităŃi sau lucrări ale tehnologiei
informaŃional - decizionale poate fi descris prin arbori de programare (scheme logice), în pseudo
- cod sau cu ajutorul tabelelor de decizii6.
a. Algoritmi şi activităŃi de proiectare clasice
Pe baza analizei de sistem a unei firme sau activităŃi complexe, echipa de proiect
delimitează clasele de entităŃi, ca fişiere / tabele principale şi secundare necesare
5
Oprean V., Oprean D., IT&C: Managementul prin proiecte,în Tribuna economică,nr. 47/2004, pag. 20-22
6
Văduva I., Programare structurată, Ed. Tehnică, Bucureşti, 1986, anexe
59
automatizărilor, precum şi procedurile şi modulele de concretizare a tehnologiei informatice.

reflectă tranzacŃiile unei perioade, terŃi (Furnizori, ClienŃi, AngajaŃi) cu care firma are relaŃii
Corespunzător schemei de sistem (organigramei) a ansamblului prelucrărilor prefigurate,
algoritmul de integrare a prelucrărilor unei aplicaŃii poate fi dat de meniul principal de
integrare a procedurilor care presupune descrierea ecranului, a formularelor de culegere a
datelor şi a obiectelor necesare (butoane, casete de dialog, liste de opŃiuni etc.) exploatării
ulterioare a programului aferent meniului.
b. Structuri ale prelucrării
Indiferent de natura prelucrărilor şi mediul de programare folosit, structurarea
proceselor de tratare a informaŃiei în cadrul unei proceduri se face prin expresii condiŃionale,
incluse în structura majorităŃii limbajelor de programare. Structurile de bază sunt:
• prelucrări secvenŃiale în care operaŃiile se succed fără reveniri sau alternări
condiŃionale
• prelucrări repetitive condiŃionale
• prelucrări repetitive cu număr finit de paşi
• generare a unor prelucrări alternative
• structuri alternative multiple
c. Proiectarea şi programarea asistată la calculator
Noile medii de programare de tip vizual, cum este Visual FoxPro sau Access, conŃin
componente şi instrumente de lucru care înlesnesc munca analiştilor şi a programatorilor. Un
astfel de instrument este managerul (constructorul) de proiecte (Project Manager) din Visual
FoxPro, ca şi generator şi gestionar de proiecte informatice. Un proiect este considerat ca
fiind un ansamblu de date cu relaŃii între ele (tabele, viziuni), programe (proceduri
„încapsulate” sau distincte), documente (formulare şi rapoarte), interogări ş.a. care definesc
o aplicaŃie. Pentru organizarea aplicaŃiei (predefinite prin analiza de sistem), un proiect se
elaborează pe baza definirii paginilor, conŃinute în fereastra constructorului.
1.11. Principiile proiectării sistemelor informatice

Pentru punerea în practică a strategiilor de mai sus, cere ca în proiectarea sistemelor
informatice trebuie să se aibă în vedere şi următoarele principii de proiectare:
1. Fundamentarea realizării sistemului pe criterii de eficienŃă economică, ce
presupune evaluarea cheltuielilor necesare pentru conceperea, realizarea, implementarea şi
exploatarea curentă a sistemului informatic şi compararea lor cu efectele economice directe şi
indirecte obŃinute de unitatea beneficiară.
2. Participarea nemijlocită a unităŃii beneficiare la conceperea şi realizarea
sistemului, care presupune adoptarea şi transpunerea în practică, de către conducerea
beneficiarului a tuturor măsurilor cu caracter organizatoric necesare desfăşurării, proiectării şi
introducerii în exploatare a sistemului, inclusiv participarea cu specialişti proprii la elaborarea
concepŃiei şi realizării efective a sistemului informatic.
3. Asigurarea calităŃii soluŃiilor abordate, ce presupune aplicarea celor mai eficiente
metode şi tehnici de proiectare şi specificarea unor caracteristici de calitate care să fie validate
şi controlate pe parcursul realizării sistemului.
4. Adoptarea de soluŃii în concordanŃă cu resursele disponibile, aceasta presupune
corelarea permanentă a proiectării sistemului informatic cu caracteristicile echipamentelor de
tehnică de calcul existente sau prevăzute a se achiziŃiona de unitatea beneficiară. SoluŃiile de
proiectare adoptate trebuie să se încadreze în fondurile alocate precum şi în funcŃie în
normativele de personal stabilite.
60
Întrebări recapitulative ale capitolului
Pe lângă aceste principii generale avem şi unele specifice sistemelor de gestiune pe

care le prezentăm în cele ce urmează.
Desfăşurarea unei activităŃi riguroase şi performante de proiectare şi realizare de
sisteme informatice de gestiune impune respectarea următoarelor principii:
1. Abordarea globală a problemei de rezolvat;
2. Utilizarea unei metodologii unitare în proiectarea şi realizarea sistemului
informatic;
3. Aplicarea celor mai moderne soluŃii şi metode de proiectare şi realizare a
sistemului informatic;
4. Structurarea sistemului informatic Ńinând seama de structura organizatorică din
cadrul firmei;
5. Participarea nemijlocită a viitorului beneficiar la activităŃile de analiză, proiectare
şi implementare a sistemului informatic. O astfel de participare asigură formularea clară a
specificaŃiilor necesare proiectării şi validarea eşalonată a soluŃiilor propuse de proiectant
toate acestea asigurând în final un produs care să corespundă deplin cerinŃelor utilizatorului;
6. Respectarea cadrului legislativ. Fiind vorba de sisteme informatice de gestiune
revine obligatorie realizarea evidenŃelor, calcularea indicatorilor şi întocmirea lucrărilor de
sinteză în conformitate cu reglementările aflate în vigoare.
7. Realizarea unor sisteme informatice corespunzătoare resurselor disponibile la
utilizator;
8. Întrucât prin natura sa software-ul este supus schimbării, această schimbare
trebuie anticipată şi controlată;
9. Compromisurile sunt inerente în dezvoltarea de software şi ele trebuie explicitate şi
documentate. Studiile de specialitate au încercat să evidenŃieze factorii de succes în
desfăşurarea proiectelor software.
Raportul Standish, spre exemplu, plasează ca primi factori de succes [23]:
• Implicarea utilizatorului final
• Sprijinul managementului executiv
• Claritatea cerinŃelor
• Planificarea
1.12. Întrebări recapitulative ale capitolului

1. Care sunt principiile sistemului?
2. Care sunt felurile interogării?
3. Cum pot fi organizate elementele sistemului?
4. Care este definiŃia sistemelor integrate?
5. Care sunt tipurile integrării?
6. Care este definiŃia sistemului informaŃional?
7. DefiniŃi noŃiunea de sistem.
8. Care sunt subsisteme unui sistem informaŃional?
9. Care sunt fazele ciclului prelucrării datelor?
10. Ce etape parcurg datele pentru a deveni informaŃii?
11. Cum este definită informaŃia?
12. Care sunt factorii persistenŃei?
13. Care sunt componentele sistemului economic?
14. Cum se defineşte sistemul integrat?
15. Câte fluxuri sunt într-o firmă şi care sunt ele?
16. Care sunt funcŃiile sistemului?
61
17. Care sunt abordările pentru managementul sistemului informatic?

18. Cum se defineşte sistemul informatic?
19. Care sunt componentele sistemului informatic?
20. Care sunt componentele SIG (Sistemului Informatic de Gestiune)?
21. EnumeraŃi cele patru tipuri de sisteme informatice.
22. DefiniŃi sistemele de prelucare a tranzacŃiilor (SPT).
23. Ce rapoarte ne dau sistemele informatice de conducere (SIC)?
24. EnumeraŃi părŃile componentelor SSD -ului (Sistem Suport de Decizie).
25. EnumeraŃi elementele fundamentale ale SE (Sistem Expert).
26. Cum se declară regulile de producŃie a unui sistem expert (SE)?
27. EnumeraŃi tipurile sistemelor expert domenii de aplicare.
28. Câte tipuri de sisteme multiexpert (SME) pot fi?
29. Care este structura unui SIAD (Sistem Interactiv de Asistare a Deciziilor)?
30. Ce modele foloseşte subsistemul modelelor de management?
31. EnumeraŃi caracteristicile EIS (Executiv Information Systems).
32. EnumeraŃi nivelurile de descompunere a Sistemului Contabil.
33. EnumeraŃi caracteristicile agenŃilor inteligenŃi.
34. Care sunt fazele ciclului de viaŃă a unui sistem informatic?
35. Care sunt demersurile prin care se definesc sistemele?
36. Care sunt elementele ce caracterizează un obiect?
37. DefiniŃia managementul proiectelor.
38. Ce este Reingineria afacerilor?
39. Care sunt componentele noilor viziuni asupra desfăşurării afacerilor?
40. Care sunt tipurile de management al unui sistem informatic al firmei?
41. EnumeraŃi strategiile după rolul sistemului informatic.
42. EnumeraŃi strategiile după modalitatea de abordare şi realizare.
43. EnumeraŃi modul de parcurgere al etapelor.
44. EnumeraŃi tehnicile organizatorice, ale tehnologiilor informatice.
45. Care sunt principiile proiectării sistemelor informatice?
46. Care sunt principiile de proiectare specifice ale unui sistem informatic de gestiune?
62
2.
Capitolul
2 NecesităŃi
2.1. Găsirea unor proiecte de dezvoltare

Aici problema esenŃială constă în nominalizarea celor ce pot fi abilitaŃi să facă
propuneri de proiecte. Practica ne arată că aceştia se pot grupa în patru categorii, astfel:
• un reprezentant al TOP-MANAGERILOR, fie directorul general a firmei
mici şi mijlocii sau un director pentru firmele mari
• un comitet de organizare ce se creează special de şefii unor compartimente
interesate
• compartimentele beneficiare printr-un şef al grupului beneficiar sau un
comitet de iniŃiativă ce decide proiectele propuse
• grupul de dezvoltare a sistemului sau reprezentantul compartimentului de
informatică
EsenŃa variantelor de proiectare propuse de cele patru situaŃii este următoarea:
Propuneri Metodă de alegere proiect Caracteristicile proiectului
Orientată puternic pe strategii
Top-managerii Proiecte de dimensiuni mari
Proiecte de durată
Orientare mixtă
De sus în jos
Schimbări organizatorice mari
Comitetul de iniŃiativă Analiza formală a costurilor
Avantajele proiectelor
Proiecte mai mari şi riscante
Limitată, neorientat strategic
Realizare rapidă
Departamentul beneficiarului
CâŃiva beneficiari reprezintă niveluri ale
conducerii şi funcŃiile firmei
De jos în sus
Integrarea în sistemul expert
PuŃine întârzieri în realizarea proiectului
Grup de dezvoltare
Mai puŃin interesat de analize de cost-
avantaje
63
2.2. Ierarhizarea proiectelor

Scopul acesteia este de a scoate în evidenŃă importanŃa propunerilor şi va fi sugerată
de cei ce fac propuneri, arătând punctele de vedere ale acestora.
La uniformizarea operaŃiilor de evaluare a proiectelor, este recomandabilă respectarea
unor criterii ca:
• alinierea strategică – care ne sugerează măsura în care proiectul atinge
obiectivele strategice ale firmei, precum şi scopurile acesteia pe termen lung;
• câştiguri posibile – care ne arată gradul cu care proiectul contribuie la
creşterea profitului, la îmbunătăŃirea calităŃii serviciilor, precum şi durata de
înregistrare a acesteia;
• disponibilitatea resurselor – care prezintă tipurile şi mărimea resurselor
solicitate, precum şi disponibilitatea lor;
• dimensiunea proiectului sau durata sa – care prezintă numărul de persoane
necesare şi durata de finalizare a acestuia;
• dificultăŃi tehnice sau riscuri – care ne prezintă nivelul acestor dificultăŃi de
realizare cu succes a proiectului într-un anumit timp şi restricŃiile de resurse.
Momentele evaluării proiectelor sunt diferite, dar de regulă, comitetele de organizare
se reunesc lunar sau trimestrial, pentru a face evaluarea noilor propuneri, faŃă de cele existente
şi pentru urmărirea proiectelor în execuŃie.
2.3. Alegerea proiectelor

Se recomandă evidenŃierea distinctă a proiectelor pe termen lung de cele pe termen
scurt, iar de aici se vor alege proiectele ce ating obiectivele firmei. Trebuie să urmărim modul
în care proiectele analizează dinamica firmei
Decizia de alegere va fi un proces complex prin care sunt luaŃi în considerare
următorii factori:
Nevoile percepute Resursele existente

şi cele reale şi disponibile
Decizia luată:
Lista proiectelor Decizia de alegere - Proiect acceptat

potenŃiale şi în curs a proiectelor - Proiect respins
- Proiect amânat
- Proiect reorientat
Mediu de organizare Criterii de evaluare - Realizat de beneficiar
- Verificarea proiectului
Figura 2.1 Criterii de alegere a proiectelor [21]
Rezultatele primei etape ale ciclului de viaŃă al dezvoltării sistemelor, este concretizată
în planificarea calendaristică a proiectelor, venite de sus în jos şi de jos în sus, ca să fie trecute
în o a doua etapă a ciclului de viaŃă, după cum reiese din figura 2.2.
64
Organizarea şi planificarea sistemului
De sus în jos:
- Top management;
- Comitet de iniŃiativă
Evaluare Planificare calendaristică

Stabilire priorităŃi a proiectelor:
Planificarea calendaristică 1. …
a proiectelor 2. …
…
n. …
De jos în sus:
- Departament utilizator;
- Grup de dezvoltare
Figura 2.2 Rezultatele după prima etapă [23]
2.4. Organizarea şi planificarea sistemului

În urma experienŃei s-a ajuns la concluzia că planificarea proiectelor nu se derulează
după un proces sistematic care duce la o alocare neadecvată a resurselor existente.
Avem unele constatări că proiectele cuprind soluŃii ce rezolvă doar probleme izolate
ale firmelor, fără o integrare în strategiile de dezvoltare a întregului sistem.
ÎmbunătăŃirea sistemului de identificare şi alegere a proiectelor, necesită luarea în
considerare a următorilor factori [21]:
• costul sistemelor informatice, care atinge aproximativ 41% din cheltuielile
totale ale firmei
• sistemele nu pot controla aplicaŃiile ce depăşesc firma
• sistemele nu rezolvă problemele stringente şi nu au aplicaŃii ce să permită
sprijinirea strategiei firmei
• redundanŃa datelor este foarte mare, iar firma nu crede în calitatea ei
• costul de întreŃinere al sistemului a ieşit de sub control, datorită învechirii lui şi
a proastei planificări, necesitând revizuirea sa
• părŃile rele ale aplicaŃiilor menŃinute mult timp, determină beneficiarii să-şi
facă propriile sisteme sau să cumpere alte aplicaŃii incompatibile cu sistemul
existent
Proiectele propuse pentru rezolvarea unor probleme trebuie să fie identificate şi
selectate în strânsă legătură cu cadrul organizatoric existent, care presupune abordarea
concurenŃială a planificării strategice a firmei şi a planificării sistemelor.
2.4.1. Planificarea sistemelor

Aceasta joacă un rol major în realizarea operaŃiunilor de identificare şi alegerea a
proiectelor. Ea fiind un ansamblu ordonat de mijloace de evaluare a cerinŃelor informaŃionale
ale unui agent şi defineşte sistemele, bazele de date şi tehnologia ce satisface aceste cerinŃe.
La planificarea sistemelor [4] [7]:
• trebuie modelate cerinŃele informaŃionale ale firmelor (de prezent şi viitor):
65
• trebuie elaborate strategiile şi planurile proiectelor ce necesită realizarea

deplasării sistemului curent şi a tehnologiei existente spre o stare viitoare
dorită.
Există următorii paşi în planificarea sistemelor:
1. SituaŃia curentă, cu: - lista prelucrărilor manuale şi automate
- lista datelor obŃinute manual şi automat
- inventarul tehnologiilor
- inventarul resurselor umane
2. SituaŃia viitoare, cu: - schiŃa prelucrărilor automate şi manuale
- schiŃa datelor obŃinute manual şi automat
- schiŃa tehnologiilor
- schiŃa resurselor umane
3. Planificarea calendaristică
IBM-ul are ca concepte cadru ale arhitecturii sistemelor informaŃionale, ce sunt
considerate ca un întreg şi reuneşte următoarele trei elemente: date, procese, reŃea.
Acestea caracterizează toate strategiile şi felul de planificare a firmei, folosind diverse
reprezentări de flux adecvat modelului economic şi tehnologic al sistemului informaŃional.
RelaŃia dintre planificarea strategică a firmei şi planul sistemului, se poate reda
schematic astfel:
Firma curentă SituaŃia curentă
Firma viitoare SituaŃia viitoare
Planul strategic Planificarea calendaristică a proiectului

Majoritate metodologilor de planificare a sistemului conŃin trei activităŃi principale :
• descrierea situaŃiei curente
• descrierea situaŃiei Ńintă şi a restricŃiilor
• elaborarea unei strategii de tranziŃie şi a planurilor
2.4.1.1. Prezentarea situaŃiei curente

Cea mai răspândită modalitate de prezentare a situaŃiei existente a firmei este
cunoscută cu numele de planificarea top-down. Ea urmăreşte determinarea cerinŃelor
informaŃionale ale firmei, începându-se cu analiza profundă a misiunii firmei, obiectivele sale
şi strategiile sale, precum şi stabilirea cu exactitate a informaŃiilor necesare atingerii
obiectivelor.
Opusă acesteia este metoda planificării bottom-up, ce presupune identificarea
problemelor firmei şi a posibilităŃilor oferite la definirea proiectelor. Această metodă este mai
scurtă şi mai ieftină, oferind avantajul de a se şti exact problemele cu care se confruntă firma.
Dezavantajul acesteia fiind că nu dă un punct de vedere de ansamblu la nivelul firmei.
Prezentarea situaŃiei curente începe cu alegerea echipei de planificare, în care sunt
incluşi executanŃi însărcinaŃi să descrie modelul situaŃiei existente.
Echipa trebuie să [7]:
• revadă toată documentaŃia firmei
• interviuri pentru manageri, executanŃi şi client
• analiza situaŃiei concurenŃională a pieŃei şi a produselor
ObŃinere informaŃiilor concludente despre situaŃia curentă ce sunt necesare identificării
şi localizării amplasamentului firmei, unităŃile sale componente, funcŃiile, procesele, datele,
sistemele informaŃionale.
66
IniŃierea proiectului
După identificarea informaŃiilor de nivel superior, ele se descompun în păŃi

componente pentru a înlesni o planificare detaliată. În urma alcătuirii listelor anteriore, se
constituie seturi de matrici, pentru scoaterea în evidenŃă a legăturilor existente între diferitele
elemente ale firmei. Avem următoarele matrici tipice:
• amplasare – funcŃie, ce identifică funcŃiile firmei executate în diferite locuri
de amplasare a afacerii:
• amplasare – unitate componentă (organizatoric), ce identifică toate
componentele amplasate într-un anumit loc sau care au legătură cu acel loc;
• componentă organizatorică – funcŃie, ce ne identifică relaŃiile existente între
entităŃile organizatorice şi fiecare funcŃie a firmei;
• funcŃie – obiectiv, care ne arată funcŃiile esenŃiale sau cele pe care dorim în
viitor ale atinge pentru obŃinerea fiecărui obiectiv;
• funcŃie – proces , ce ne arată fiecare proces folosit în realizarea fiecărei
funcŃii;
• funcŃie – entitate date, ne identifică toate funcŃiile ce folosesc toate tipurile de
date necesare acestora;
• proces – entitate de date, ne identifică datele culese, utilizate, actualizate sau
şterse de fiecare proces;
• proces – sistem informaŃional, ne identifică datele create, actualizate,
consultate sau şterse din fiecare sistem;
• sistem – obiective, ne identifică sistemele după modul în care acestea
contribuie la atingerea obiectivelor.
2.4.1.2. SituaŃiile Ńintă şi restricŃiile lor

Acesta este următorul pas în procesul de planificare a sistemului, reflectând starea
viitoare a firmei.
Ele prezintă starea viitoare dorită a amplasamentelor afacerilor, a componentelor
organizatorice, a funcŃiilor , proceselor, datelor, sistemelor, în strânsă legătură cu restricŃiile şi
tendinŃele firmei, ale mediului unde îşi desfăşoară activitatea, factorii de timp, resurse,
evoluŃie tehnologică, concurenŃă, etc. Apoi se va actualiza matricele, astfel ca să existe o
corelaŃie strânsă între informaŃiile ce descriu starea viitoare a firmei.
Planificatorii vor scoate în evidenŃă diferenŃele dintre listele şi matricele curente şi
cele viitoare, pentru identificarea proiectelor şi strategiilor de tranziŃie.
2.5. IniŃierea proiectului

După alegerea proiectului se trece la faza de iniŃiere, care presupune desfăşurarea unei
activităŃi laborioase, ce este efectuată de managerul proiectului şi care răspunde de [7]:
• elaborarea unor studii de fezabilitate generale
• elaborarea planurilor detaliate ale proiectelor
• găsirea celor mai buni membrii ai echipei de proiectare
Managerul trebuie să desfăşoare activităŃi ca:
• conducere
• administrare
• relaŃii bune cu clienŃii
• rezolvarea problemelor tehnice
• managementul conflictelor de interese
67
• managementul echipei
• managementul riscului şi al schimbării
Un manager trebuie să aibă următoarele calităŃi:
• analitice
• manageriale
• tehnice
• interpersonale
În această fază se desfăşoară următoarele activităŃi:
• stabilirea echipei de iniŃiere a proiectului
• stabilirea bunelor relaŃii cu beneficiarul
• stabilirea procedurilor manageriale
• stabilirea cadrului de desfăşurare a proiectului şi a manualului de operare al
acestuia
Manualul de operare trebuie să conŃină următoarele elemente;
• prezentarea generală a proiectului
• planurile iniŃiale şi cererile de serviciu ale sistemului
• aria şi riscurile proiectului
• proceduri manageriale
• descrierea datelor
• corespondenŃa echipei
• rapoarte de lucru
• planificarea calendaristică a proiectului
2.6. Planificarea proiectului

Aceasta este un proces diferit de planificarea generală şi va cuprinde o evaluare a
cerinŃelor informaŃionale ale sistemului la nivelul integrării firme.
Ea cuprinde următoarele activităŃi [4] [7]:
• descrierea ariei de întindere a variantelor şi fezabilităŃile proiectului
• descompunerea proiectului în activităŃi uşor executabile şi controlabile
• estimarea resurselor şi crearea unui plan al resurselor
• realizarea unei prime planificări calendaristice
• realizarea unui plan al comunicărilor
• determinarea standardelor şi procedurilor proiectului
• identificarea şi evaluarea riscului
• crearea unui buget preliminar
• întocmirea rapoartelor de activitate
• definitivarea planului de bază al proiectului
După această activitate urmează cea de execuŃie a proiectului, când se pune în aplicare
planul de bază al acestuia.
2.7. Analiza de fezabilitate

Un proiect poate să coaste miliarde de lei şi se poate realiza pe parcursul a 3-6 ani,
pentru a fi complet. Atunci este normal ca managerii să demareze proiectare sistemului după
ce se efectuează studiul de fezabilitate.
68
Analiza de fezabilitate
Acesta are rolul de asigurare a unor informaŃii obiective necesare cunoaşterii realităŃii
în demararea unui proiect sau nu, sau dacă el mai poate continua sau dacă a fost întrerupt.
Fezabilitatea proiectului poate fi studiată în orice fază a elaborării sale, dar studiile se
efectuează de regulă în momente certe.
La alegerea unui proiect, se va efectua un studiu preliminar de fezabilitate, care va
stabili dacă proiectul atinge obiectivele propuse de firmă. Analiza poate fi oricât de
subiectivă, fiind-că proiectul ne este prezentat în amănunŃime la demararea sa. Posibilitatea
unor analize de fezabilitate concludente, cere efectuarea studiilor de fezabilitate în diverse
faze ale ciclului de viaŃă a sistemelor.
Acest studiu trebuie să conŃină următoarea documentaŃie [4] [7]:
• definirea problemei
• descrierea cerinŃelor sistemului
• descrierea soluŃiilor sistemului propus
• explicaŃia critică a motivării studiului întreprins
• cuantificarea tuturor costurilor materiale şi beneficiile aferente
• lista costurilor şi beneficiilor necuantificate
2.7.1. Felurile analizei de fezabilitate

Problemele ce se evaluează cu studiul de fezabilitate include: fezabilitatea tehnică,
economică, de exploatare, a legalităŃii şi a programării.
Fezabilitatea tehnică, are ca problemă esenŃială, dacă sistemul poate fi elaborat şi
implementat de beneficiar, prin folosirea tehnologiei existente, fiind-că progresele tehnologice
sunt mult mai rapide decât posibilităŃile financiare ale beneficiarului pentru a se introduce.
Fezabilitatea economică, ce ridică două probleme, una ce justifică sistemul propus,
timpul, banii, alte resurse şi costurile necesare implementării. Cealaltă, existenŃa fondurilor
necesare la beneficiar pentru elaborarea şi implementarea sistemului, deoarece sunt cerinŃe de
fonduri şi pentru alte proiecte.
Fezabilitatea exploatări, ce porneşte de la întrebarea: Este posibil ca noul sistem să fie
utilizat de persoanele cărora le este adresat? Deoarece schimbarea implică şi o doză de risc.
Fezabilitatea legalităŃii, ce urmăreşte să stabilească dacă se pot înregistra conflicte
între sistemul propus şi posibilităŃile firmei de a nu avea anumite conflicte faŃă de obligaŃiile
legale.
Fezabilitatea programării, ce răspunde la întrebarea: Se poate proiecta şi implementa
sistemul în timpul alocat? Ce din păcate, nici tehnologiile noi nu aduc reducerea majoră a
timpului de proiectare şi implementare, ca motivaŃie ar fi, neadaptarea personalului la acestea.
2.7.2. Stabilirea costurilor şi beneficiilor proiectului

Cadrul legal de bază îl constituie modelul bugetelor de capital.
Modelul presupune estimarea cu rigurozitate a costurilor iniŃiale, a celor de exploatare,
precum şi a altor consumaŃii de valori, a economiilor şi a beneficiilor pentru fiecare an de
utilizare a sistemului.
Cheltuielile iniŃiale şi de exploatare au următoarea structură [7]:
• echipamente
• costurile îmbunătăŃirii sistemului
• software
• documentaŃie
• personal
• pregătirea locului de muncă
69
• cheltuieli de instalare
• testarea sistemului
• materiale de birou
• regie
• siguranŃă şi întreŃinere
• financiare
Cheltuielile iniŃiale sunt cele cu echipamentele, cele cu exploatarea dacă sistemul e
închiriat, apoi cheltuielile cu personalul şi cheltuieli cu testarea, acestea fiind cele mai
importante.
Unele beneficii aduse de sistem sunt [4]:
• economie din reducerea personalului funcŃionăresc
• creşterea capitalului circulant prin reducerea stocurilor, a soldurilor, etc.
• servicii de bună calitate prestate clienŃilor
• creşterea productivităŃii muncii în Ńinerea evidenŃei şi efectuarea analizelor
• îmbunătăŃirea procesului de luare a deciziei
• control eficient în utilizarea programelor speciale
• reducerea costurilor de exploatare
2.8. Moduri de reprezentare a planurilor şi programelor

calendaristice
Conducătorul de proiect are la îndemână o mare varietate de tehnici de reprezentare şi
descriere a planurilor de proiect.
DocumentaŃia planificării poate fi alcătuită din:
• rapoarte grafice (Gantt şi PERT);
• rapoarte sub formă de text.
Digrama Gantt este o modalitate de reprezentare grafică a proiectului cu ajutorul unor
bare orizontale, prin care sunt prezentate activităŃile, iar lungimea lor este proporŃională cu
timpul alocat acelei activităŃi. Putându-se utiliza diferite culori, forme sau umbre, ce vor
scoate în evidenŃă unele activităŃi.
Aceste diagrame nu arată ordinea activităŃilor, ci data începerii şi finalizării lor. Ele
sunt recomandate pentru proiecte simple sau pentru unele componente ale unor proiecte mari.
Diagrama PERT (Program Evaluation Review Technique) este o altă modalitate de
reprezentare grafică a activităŃilor unui proiect şi a relaŃiilor dintre acestea. EsenŃa sa constă în
faptul că scoate în relief şi ordinea de execuŃie a activităŃilor, prin prezentarea predecesorilor
şi a succesorilor.
PERT prezintă secvenŃele de activităŃi componente ale unui proiect sub formă de reŃea
de săgeŃi şi noduri. SăgeŃile prezintă sarcinile sau activităŃile ce presupun anumite resurse şi
un tip de execuŃie, iar nodurile reŃelei reprezintă evenimentele sau reperele proiectului.
Evenimentul este un punct în timp, dar pentru el nu se alocă timp de execuŃie.
Primul aspect al tehnicii PERT este de analiză a reŃelei prin prisma timpilor necesari
fiecărei activităŃi şi a proiectului în întregime. Fiecare activitate are un timp de realizare în
ore, zile, săptămâni, luni. Apoi se va stabili drumul critic al reŃelei, deci, calea activităŃilor
de la începutul şi până la sfârşitul reŃelei, ce necesită volumul maxim de timp consumat.
Întârzierea în execuŃie a unei activităŃi critice duce la influenŃarea întregului proiect.
Diagrama PERT este preferabilă celei Gantt sau invers, în funcŃie de următoarele
aspecte [4] [7]:
• Gantt vizualizează durata activităŃii, iar PERT vizualizează dependenŃa unor
70
Cuplarea
activităŃi de altele
• Gantt evidenŃiază suprapunerea activităŃilor în timp, PERT nu, dar poate
prezenta în paralel activităŃile respective
• unele diagrame Gantt arată şi diferenŃele de timp, PERT arată aceste elemente
prin menŃionarea datelor în interiorul dreptunghiurilor
Modificările termenilor, activităŃilor, etc., pot fi uşor calculate şi corelate imediat cu
celelalte, prin folosirea softului Microsoft Project 2007.
2.9. Cuplarea
2.9.1. Cuplarea elementelor

Există mai multe nivele ale cuplării [21] [44]:
5. cuplarea datelor
4. cuplarea matriŃelor
3. cuplarea de control
2. cuplarea obişnuită
1. cuplarea elementelor
Două module au cuplare de elemente dacă unul dintre ele se referă direct la elementele
celeilalte. De exemplu: modulul p modifică o instrucŃiune a modulului q.
Această practică nu este limitată la limbajele de asamblare. În Cobol există verbul
“alter” care face acest lucru. Când două module sunt astfel cuplate, ele sunt iremediabil
legate.
2.9.2. Cuplarea obişnuită

Două module sunt cuplate obişnuit dacă ambele au acces la aceleaşi date globale.
Există o altă cale de a implementa cuplarea obişnuită folosind instrucŃiunea “common “ din
Fortran-ul nestandard, “global” în COBOL ’80 sau “public” în Visual C++ şi Java.
Dacă în faza de menŃinere este făcută o schimbare într-un modul la declararea unei
variabile globale atunci toate modulele care au acces la acea variabilă trebuie schimbate.
Un alt dezavantaj este faptul ca acesta cuplare contravine spiritului programării
structurate şi pot exista efecte secundare care afectează inteligibilitatea modulului. Ar mai
putea apărea o problemă deoarece astfel de module sunt greu de reutilizat şi pentru că
modulul poate avea mai multe date decât necesar, ceea ce face grea încercarea de a controla
accesul la date.
Pentru a uşura munca, pot fi folosite baze de date, dar dacă limbajul nu se pretează la
aşa ceva, se poate folosi cuplarea obişnuită, dar într-un mod controlat. În aceste situaŃii o
supraveghere îndeaproape a unui manager poate reduce unele riscuri. O altă alternativă ar fi
utilizarea ascunderii de informaŃie aşa cum vom vedea în alte paragrafe ale aceste cărŃi.
2.9.3. Cuplarea de control

Două module sunt cuplate prin control dacă unul dintre ele trece un element de control
celuilalt. De exemplu: se face transfer de control atunci când un cod de funcŃie este transferat
unui modul cu unitate logică sau când are loc o schimbare de control ca şi argument.
Problema care se ridica este ca cele două module nu sunt independente, deci posibilitatea de
refolosire se reduce. În plus cuplarea prin control este în general asociată cu module care au
unitate logică şi deci dezavantajele acesteia sunt prezente.
71
2.9.4. Cuplarea matriŃelor

În unele limbaje de programare numai variabilele pot să apară ca argumente. Două
module sunt cuplate prin matriŃe dacă o dată structurată este transferată ca şi argument, dar
modulul apelat operează numai asupra unei componente a acestei date.
Avantajul acestei cuplări constă în faptul că modulul rezultat şi interfaŃa sunt mai uşor
de înŃeles şi se poate reutiliza uşor şi la alte produse.
Nu este nimic greşit în a transfera o structură de date ca argument astfel încât toate
componentele sale să fie folosite în procedura apelată, dar în acest caz nu este vorba de
cuplarea prin matriŃe.
O formă subtilă a unei astfel de cuplări poate apărea în C şi C++ dacă un pointer spre
un articol este folosit ca argument.
2.9.5. Cuplarea datelor

Două module sunt cuplate prin dată dacă toate argumentele sunt omogene din punctul
de vedere al datei, adică fiecare argument este fie un argument simplu, fie o structură de date.
O astfel de cuplare este un scop dezirabil. Dacă un produs are numai cuplări prin date
nu vor exista dificultăŃi de la celelalte genuri de cuplări, menŃinerea va fi mai uşoară.
2.9.6. ImportanŃa cuplării

Cuplarea este o mărime importantă. Dacă modulul a este strâns legat de modulul b
atunci o schimbare în b cere şi o schimbare în a. Dacă această schimbare este făcută în faza de
integrare sau menŃinere, produsul va funcŃiona corect, totuşi progresul în această fază va fi
încetinit. Pe de altă parte dacă schimbarea în a nu este făcută, eroarea se va manifesta mai
târziu, când greşeală este greu de găsit.
DefiniŃia clasică a cuplării, este gradul de interacŃiune dintre două module, dar
conform acesteia este greu de măsurat. Este nevoie de o mărime mai complexă cu un nivel de
abstracŃie mai scăzut. O astfel de mărime este mărimea dependenŃei de cuplare (CDM). Fiind
dat un modul a, CDM este o măsura a modurilor în care o schimbare a produsului va cere o
schimbare în a. De exemplu: dacă a utilizează o variabilă globală x atunci a va trebui să
schimbe tipul variabilei x dacă acesta s-a modificat de la int la real sau dacă numele s-a
modificat în y.
Cuplarea este la fel de eficientă ca mărime pentru paradigma clasică sau cea orientată
pe obiect.
2.10. Încapsularea datelor

Să consideram problema proiectării unui sistem de operare mai amplu. Conform
specificaŃiilor orice muncă va fi clasificată într-una din clasele [21] [44]:
• Prioritate maximă
• Prioritate medie
• Prioritate scăzută
Pentru a decide care activitate va fi încărcată în faza următoare şi cât de lung va fi
timpul acordat ei sistemul de operare trebuie să aibă în vedere priorităŃile fiecărei activităŃi. Se
formează o coadă de activităŃi care trebuie să fie iniŃializată şi trebuie să existe facilităŃi de
adăugare a unei activităŃi la coadă atunci când este nevoie sau de înlăturare, când SO
(sistemul de operare) decide să aloce resursele necesare îndeplinirii activităŃii.
72
Tipuri abstracte de date
2.10.1. Încapsularea datelor şi dezvoltarea produsului

Încapsularea datelor este un exemplu de abstractizare. Conceptul teoretic de la care se
porneşte este rafinamentul în trepte. Mai întâi se proiectează la un înalt nivel noŃiuni ca:
activităŃi, cozi de operaŃii, operaŃiile care trebuie efectuate asupra cozilor. La acest stadiu este
irelevant modul în care coada este implementată. Urmează proiectarea componentelor la un
nivel mai scăzut când vor fi implementate datele structurate şi operaŃiile asupra lor.
Conceptul de nivele de abstractizare a fost descris de Djikstra în termeni arhitecturali,
astfel [21] [44]:
• Nivelul cinci – limbaj orientat pe problemă
• Nivelul patru – limbaj de asamblare
• Nivelul trei – sistemul de operare
• Nivelul doi – cod maşină
• Nivelul unu – microprogramare
• Nivelul zero – logica digitală
În C funcŃiile sunt un exemplu de abstractizare procedurală. Încapsularea poate fi
definită ca totalizarea aspectelor entităŃii lumii reale modelate de acel unit. Abstractizarea
datei permite proiectantului să se gândească la nivelul structurii de date şi la operaŃiile
efectuate cu ea şi abia mai apoi să se concentreze asupra detaliilor, ca de exemplu: cum va fi
acea dată implementată. Efectul este de a extinde limbajul cu altă funcŃie care nu este parte a
celui iniŃial definit. ImplicaŃiile abstractizării procedurale pentru proiectare sunt tot atât de
puternice ca şi cele ale abstactizării datelor. Aceste acŃiuni pot fi definite la nivel scăzut până
când cel mai scăzut nivel este atins, apoi acŃiunile sunt exprimate în termenii constructorilor
predefiniŃi ai limbajelor de programare. La fiecare nivel proiectantul se ocupă numai de
exprimarea produsului în termenii corespunzători acelui nivel. Proiectantul poate ignora
nivelul inferior de care se va ocupa la momentul potrivit şi acesta înseamnă rafinament în
trepte. Proiectantul poate ignora deasemenea şi nivelul superior care este irelevant din punctul
de vedere al nivelului curent.
2.10.2. Încapsularea datelor şi menŃinerea produsului

Abordând încapsularea datelor din punctul de vedere al menŃinerii, o problemă de bază
este identificarea acelor aspecte ale produsului care sunt foarte probabil de schimbat şi
proiectarea produsului în aşa fel încât să se minimizeze efectele viitoarelor modificări.
Să presupunem că folosim o listă lineară pentru implementarea cozii, dar s-a luat o
decizie pentru reimplementarea ei ca o listă dublă de articole. Fiecare activitate va avea trei
componente, anume [7]:
• Număr
• Legătură predecesor
• Legătură succesor
2.11. Tipuri abstracte de date

Implementarea cozii de activităŃi class, adică un tip de dată împreună cu operaŃiile
care se pot efectua. O astfel de construcŃie este numită tip abstract de date.
Prezentăm modul în care un tip abstract de dată poate fi utilizat pentru cele trei cozi ale SO:
• highpriorityqueue
• mediumpriorityqueue,
• lowpriorityqueue
73
Tipurile abstracte de date suportă atât abstractizarea datei cât şi cea procedurală. În
plus, când produsul este modificat este puŃin probabil ca tipurile abstracte de date să fie
schimbate, în cel mai rău caz operaŃiile adiŃionale s-ar putea să trebuiască a fi adăugate la un
tip abstract de date. De aceea, din punctul de vedere al dezvoltării şi menŃinerii produsului
tipurile abstracte de date sunt foarte atractive.
Un al treilea tip de abstractizare este cea a iteraŃiei, care permite programatorului să
specifice la un nivel înalt folosirea unui ciclu şi apoi să descrie la un nivel scăzut elementele
exacte asupra cărora iteraŃia va fi realizată.
2.12. Ascunderea informaŃiilor

Cele trei tipuri de abstractizări discutate sunt incluse într-un concept mai general
introdus de Parnas “ascunderea informaŃiei“. Ideea lui este direcŃionată spre menŃinerea în
viitor, înainte ca un produs să fie proiectat ar trebui implementată o listă care să conŃină
posibilele decizii de modificare din viitor.
Modulele ar trebui astfel proiectate încât detaliile de proiectare rezultate să fie
ascunse în alte module, atunci orice schimbare viitoare va fi localizată într-un anumit modul.
O unitate scăzută a modulelor şi o cuplare strânsă pot aduce dificultăŃi pe care
managerul trebuie să le reorganizeze astfel încât produsul să nu fie vulnerabil la fraude. De
exemplu: proiectantul Java oferă pentru ascunderea informaŃiei o clasă specifică.
Tehnicile de ascundere a informaŃiei pot fi folosite şi pentru a evita cuplarea obişnuită.
2.13. Obiecte
Felul în care s-a progresat şi s-a ajuns la noŃiunea de obiect se prezintă în continuare.
Să dăm o definiŃie incompletă a obiectului: “un caz particular de dată abstractă”,
adică un produs e proiectat în termeni de date abstracte şi variabilele produsului sunt exemple
de tipuri de date abstracte.
Ideea de bază a programării orientate pe obiect care se caracterizează prin proprietatea
de moştenire, ce este ca un nou tip de dată, care poate fi definit ca extensie a tipurilor definite
anterior în loc să se pornească de la zero.
Într-un limbaj orientat pe obiect pot fi definite clase. O clasă este un tip de dată
abstract care suportă moştenirea. Un obiect este un instanŃier al unei clase.
Proprietatea de moştenire este o însuşire esenŃială a limbajelor de programare orientate
pe obiect. Nici proprietatea de moştenire şi nici conceptul de clasă nu există în limbajele
clasice, ca de exemplu: C, Cobol, Fortran.
Asocierea se referă la relaŃii de un anumit fel între două clase aparent independente.
Avantajele folosirii obiectelor sunt în general aceleaşi cu cele ale folosirii tipurilor de
date abstracte. În plus, un alt punct forte rezultă din combinarea proprietăŃii de moştenire cu
polimorfismul şi legarea dinamică.
2.14. Moştenire, polimorfism şi legare dinamică

Să presupunem că SO al unui computer este apelat pentru a deschide un fişier care
poate fi stocat pe medii diferite. Folosind paradigma structurată am avea nevoie de funcŃii
deferite. Dacă folosim paradigma orientată pe obiect putem defini o clasă.
74
Unitatea şi cuplarea obiectelor
Datorită legării dinamice nu este necesar să se determine care metodă trebuie apelată
pentru a deschide un fişier. Este suficient să trimitem un mesaj şi sistemul va determina tipul
pentru a apela metoda corectă.
Aceasta idee este aplicabilă nu numai la metode abstracte. Consideram o ierarhie pe
clase, în care toate clasele sunt derivate prin moştenire din clasa de bază. Să presupunem ca
procedura checkorder (b:base) ia ca argument un instanŃier al clasei de bază, apoi ca o
consecinŃă a moştenirii polimorfismului şi legării dinamice se poate apela aceasta procedură
nu numai cu un argument de tipul clasei de bază, dar şi cu orice altă subclasă a ei. Această
tehnică este foarte puternică deoarece profesioniştii nu mai trebuie să se ocupe pentru tipul
argumentului. Totuşi există dezavantaje ale polimorfismului şi legării dinamice, cum ar fi:
• La compilare nu se ştie cu exactitate care anume dintre metode va fi apelată în
momentul execuŃiei şi cauza unui eşec este greu de determinat
• Poate avea un efect negativ asupra menŃinerii, fiind greu de înŃeles
Totuşi, motivul superiorităŃii acestei paradigme este dată de independenŃa fizică şi
conceptuală.
2.15. Unitatea şi cuplarea obiectelor

Un obiect este un fel de modul, deci tot ceea ce s-a spus despre unitatea şi cuplarea
modulelor poate fi aplicat şi în cazul obiectelor. Se ridică problema dacă există tipuri speciale
de cuplări în cadrul paradigmei orientate pe obiect. Mai întâi să considerăm unitatea unui
obiect. O clasă poate conŃine două tipuri de acŃiuni, anume [21] [44]:
• metode moştenite
• metode specifice
Unitatea unei clase este determinată din funcŃionalitatea ei. Să presupunem că 2 clase
au funcŃionalitate identică. Una dintre ele moşteneşte totul de la o clasă superioară, iar cealaltă
nu moşteneşte nimic. Pentru că au funcŃionalităŃi identice au şi acelaşi nivel de unitate. Cu
alte cuvinte nu există tipuri specifice de unitate în funcŃie de clase, unitatea se aplică în mod
egal tuturor tipurilor de module, inclusiv claselor.
În ceea ce priveşte cuplarea să ignorăm mai întâi moştenirea şi deci cuplarea a două
clase poate fi determinată ca şi în cazul paradigmei clasice. De exemplu: dacă un atribut al
unei clase e definit public, acesta va induce o cuplare obişnuită.
Ceea ce este surprinzător totuşi este că moştenirea nu induce noi forma de cuplare.
Atunci în ciuda marilor diferenŃe dintre paradigma clasică şi cea orientată pe obiect, cea din
urmă nu induce noi forme nici de unitate şi nici de cuplare.
Un număr specific de mărimi ale paradigmei orientate pe obiect au fost puse în
evidenŃă, ca de exemplu: înălŃimea arborelui de moştenire. Unele din aceste mărimi au fost
puse la îndoială atât teoretic cât şi practic. În aceste cazuri rămâne de arătat că există nevoia
unor mărimi orientate pe obiect, altele decât cele clasice. Un argument în plus este faptul că
folosirea obiectelor şi claselor facilitează reutilizarea.

1. EnumeraŃi cele patru grupe de categorii de dezvoltare a proiectelor.
2. EnumeraŃi criteriile de evaluare a proiectelor.
3. Care sunt criteriile de alegere a proiectelor?
4. Care sunt factorii de identificare şi alegerea proiectelor?
5. Care sunt activităŃile metodologiei de planificare a sistemelor?
75
6. Ce face echipa pentru situaŃia curentă?

7. De ce răspunde managerul proiectului.
8. Ce trebuie să conŃină manualul de operare al proiectului?
9. Care sunt calităŃile unui manager?
10. Care sunt activităŃile planificării proiectului?
11. Care sunt documentele studiului de fezabilitate?
12. EnumeraŃi fluxurile fezabilităŃii.
13. Care sunt beneficiile aduse sistemului?
14. DefiniŃi diagrama GANTT.
15. DefiniŃia diagrama PERT.
16. EnumeraŃi nivelele cuplării.
17. Care sunt nivelele de abstractizare în termeni arhitecturali?
18. Care sunt componentele încapsulării?
19. Ce acŃiuni cunoaşte o clasă?
20. DefiniŃia clasei.
76
3.
Capitolul
3 Analiza sistemelor
3.1. Scopul şi fazele de realizare a analizei
3.1.1. Analiza – diagnostic informaŃională

Aceasta constituie o adaptare a tehnicii analizei – diagnostic, care este o tehnică de
analiză economică folosită la studiul sistemului informaŃional-decizional deci, este un tip de
analiză-diagnostic specializată.
Analiza-diagnostic este orientată către probleme de organizare şi conducere ale unităŃii
economice şi constă în controlarea şi evaluarea nivelului de funcŃionare a sistemului de
conducere şi a celui condus, identificarea şi localizarea fenomenelor negative şi a cauzei
apariŃiei lor (diagnosticare), precum şi în elaborarea unor recomandări menite să permită o
funcŃionare eficientă a sistemelor respective.
Studiul sistemului condus nu constituie un scop în sine al analizei - diagnostic, ci e
legat de studiul sistemului de conducere, deoarece un sistem de conducere poate fi studiat
astfel [21] [44]:
• direct – prin analiza activităŃii propriu-zise a organelor de conducere
• indirect – prin analiza activităŃii şi a rezultatelor sistemului condus, plecând de
la premisa că aceste reprezintă reflectarea activităŃii de conducere
Deci, analiza-diagnostic este alcătuită din două părŃi:
• stabilirea diagnosticului – a stării sistemului studiat şi a perturbaŃiilor
intervenite, care determină starea;
• elaborarea recomandărilor
Analiza-diagnostic informaŃională constă în cunoaşterea sistemului informaŃional-
decizional şi evaluarea lui din punct de vedere al eficienŃei şi a utilităŃii sale pentru sistemul
de conducere.
Ea realizează doar partea de diagnostic, în timp ce elaborarea măsurilor de prevenire /
înlăturare a perturbaŃiilor este inclusă implicit în proiectul noului sistem.
Analiza-diagnostic informaŃională se încadrează în metoda mixtă de abordare a
sistemului-obiect cu punctul de plecare de la componenta critică, deoarece:
• poate urma după o analiză-diagnostic tehnico-economică, efectuată în cadrul
acŃiunilor pregătitoare realizării sistemului informatic cu scopul de a delimita
domeniile critice, ea axându-se pe aspectele informaŃionale ale acestor domenii
• poate pleca de la premisa că sistemul informaŃional-decizional al unităŃii este o
componentă c e trebuie efectuată, ea având scopul de a delimita componentele
critice ale sistemului informaŃional-decizional, pentru orientarea analizelor în
etapele următoare
77
Scopul analizei-diagnostic informaŃională, este:

• de a oferi o imagine completă a organizării şi funcŃionării sistemului existent
• de a evidenŃia defectele de funcŃionare şi carenŃele de organizare ale acestui
sistem
• de a stabili cerinŃele pentru realizarea sistemului informatic
Analiza-diagnostic informaŃională îşi propune stabilirea stări sistemului
informaŃional-decizional şi a perturbaŃiilor care conduc la aspecte negative.
Obiectivele acesteia sunt diferenŃiate în funcŃie de aria de cuprindere a acesteia [21]:
• cea generală urmăreşte să stabilească aspectele informaŃional-decizionale şi de
conducere la nivelul întregii unităŃi şi legat de aceasta: obiectivele şi orientarea
generală a unităŃii, precum şi aspectele de organizare şi conducere la nivelul
unităŃii;
• cea parŃială urmăreşte să stabilească problemele de prelucrare a informaŃiilor
relative la deciziile existente la nivelul domeniului şi legat de aceasta: modul
de organizare şi conducere al activităŃilor din acel domeniu, precum şi modul
de aplicare a metodelor şi tehnicilor de organizare şi conducere în raport cu
cerinŃele domeniului.
Ea studiază ambele structuri ale unităŃii, funcŃională şi organizatorică, însă doar în
legătură cu structurarea pe criterii organizatorice a activităŃii, deciziilor şi informaŃiilor.
Etapele de realizare a analizei sunt de obicei cele ale analizei-diagnostic în general,
dar o serie de paşi sunt omişi sau au alt conŃinut decât al analizei tehnico-economice. Ea se
încadrează în metoda mixtă de abordare a sistemului-obiect cu punct de plecare de la
componenta critică.
Etapele de realizare sunt:
a. Pregătire analizei, care constă în: formarea echipei şi organizarea analizei şi
elaborarea formularelor speciale de culegere a datelor;
b. Analiza sistemului existent, care constă în: culegerea informaŃiilor, sistematizarea
informaŃiilor culese şi evaluarea sistemului existent. Evaluarea constă în: evaluarea
funcŃionării sistemului existent cu diverse criterii de evaluare şi stabilirea aspectelor critice ale
sistemului analizat (analiza critică a sa), pe baza diferitelor criterii şi cerinŃe.
Activitatea de analiza-diagnostic informaŃională se încheie practic cu o sinteză sau
raport de analiză, care cuprinde [21]:
• generalităŃi
• prezentarea sistemului informaŃional-decizional
• analiza critică a sistemului existent
• restricŃii şi condiŃii de introducere a noului sistem
Avantajul acestei analize constă în faptul că, prin evidenŃierea aspectelor negative şi
gruparea lor în puncte critice, facilitează şi orientează analizele din următoarele etape de
realizare a sistemului informatic.
RestricŃiile în aplicarea aceste tehnici sunt determinate de:
• necesitatea includerii în echipă a unor specialişti în domeniul analizat, chiar în
condiŃiile când analiştii sunt familiarizaŃi cu acel domeniu
• necesitatea delimitării prealabile a domeniilor analizate
3.1.2. Analiza celulară

Tehnica analizei celulare este una de analiză complexă, utilizată în cadrul metodei de
abordare descendentă a sistemului-obiect, atât pe componente cât şi pe activităŃi şi care oferă
informaŃiile necesare:
• proiectarea sistemelor informatice complexe pentru unităŃi economico-sociale
78
Scopul şi fazele de realizare a analizei
• raŃionalizarea sistemului existent, respectiv reordonări fluxului de informaŃii şi

standardizării evidenŃelor
• simulării unor posibile reorganizări ale unităŃii, precum şi îndeplinirii sarcinilor
de serviciu, pentru lucrătorii unităŃii după efectuarea acestor reorganizări
Această tehnică este de abordare top-down a sistemului obiect şi utilizează conceptele
de structurarea, orientat pe organism şi cel orientat pe activitate, iar analiza se va face în trei
etape [7] [21] [44]:
• prima, tratează structura organizatorică a întregului sistem studiat
• a doua, tratează structura funcŃională a sistemului şi/sau a subsistemelor
• a treia, efectuează analiza informaŃiilor vehiculate în sistem, informaŃii care
constituie legătura între cele două structuri
Scopul aceste tehnici este obŃinerea unor imagini analitice descriptive, detaliate,
despre sistemul obiect, în general şi al sistemului informaŃional-decizional în special, atât ca
organizare cât şi ca funcŃionare. Ea se poate folosi astfel:
• la realizarea sistemelor informatice complexe pentru unităŃi economico-sociale
• la realizarea bazei de date a sistemului informatic, datorită faptului că
foloseşte, la determinarea cerinŃelor, o abordare pornind de la analiza datelor
Elementele de bază a unei astfel de structuri este celula, adică elementul component
de pe ultimul nivel de agregare, ce nu se mai poate divide.
O celulă este descrisă prin: intrările (X), ieşirile (Y) şi operatorul (T), astfel:
X Y
T
Intrările celulei suferă o serie de transformări devenind ieşirile celulei.
Fiecare celulă se leagă de alte celule doar prin intrări şi ieşiri, formând structuri de
celule, de tip [21]:
• lanŃuri de celule (deci legate în serie)
• arbori de celule (deci legate în paralel)
• structuri complexe (agregări ale primelor două)
Descrierea sistemului este făcută iterativ pe principiul descompunerii top-down, în
următoarele etape:
• delimitarea sistemului analizat
• stabilirea structurii sistemului studiat
• stabilirea intrărilor şi transformărilor succesive ale intrărilor şi ieşirilor la
nivelul subsistemelor
Paşii de realizarea a aceste analize sunt:
• culegerea datelor
• sistematizarea informaŃiilor
• evaluarea sistemului informaŃional-decizional cu diagnosticarea acestuia
Rezultatul aplicării aceste tehnici constă în imaginile analitic-descriptive ale
sistemului obiect.
Tehnica analizei celulare oferă o imagine completă şi foarte detaliată a sistemului
obiect, se foloseşte pentru sistemele complexe. Ea este o tehnică foarte laborioasă şi necesită
multă răbdare pentru completarea corectă şi completă de culegere specifice.
3.1.3. Tehnici de analiză ce pot fi utilizate şi în etapa de proiectare

Procesul de analiză poate fi sistematizat astfel [7]:
• stabilirea funcŃiei de analizat
79
• detalierea funcŃiei prin analiză, iar funcŃiile obŃinute sunt toate părŃi ale funcŃiei
iniŃiale
• reprezentarea rezultatului analizei într-o formă grafică adecvată
Procesul de proiectare se realizează prin luarea în considerarea a unui set de principii,
ce are ca rezultat o ierarhie funcŃională reprezentată printr-o schemă de structură arborescentă.
Tehnica în principiu se aseamănă cu procesul de analiză generală a unei faze. Relativ
la această tehnică de analiză se pun două întrebări [7]:
• De unde vin funcŃiile care urmează să fie analizate?
• Ce şi care sunt principiile de analiză?
Principiile de analiză sunt [21] [44]:
a) Analiza trebuie să conducă la reflectarea caracteristicilor externe ale funcŃiilor
în caracteristicile interne ale sistemului.
b) Analiza trebuie să conducă la identificarea unei secvenŃe liniare de execuŃie a
funcŃiilor.
c) Analiza trebuie să conducă la selectarea funcŃiilor alternative.
d) Analiza trebuie să conducă la identificarea funcŃiilor interactive.
e) Analiza trebuie să conducă la o delimitarea precisă a intrărilor, transformărilor
şi ieşirilor.
f) Analiza trebuie să conducă la plasarea funcŃiilor de acŃiune într-o poziŃie
subordonată funcŃiilor de decizie care le afectează.
g) Analiza trebuie să conducă la izolarea, cu subfuncŃii, a celor subfuncŃii a căror
realizare este condiŃionată de o decizie ulterioară de proiectare.
h) Analiza trebuie să conducă la minimalizarea transferului de date dintre funcŃii
prin prevederea de funcŃii specifice pentru modificarea distanŃei datelor.
i) Analiza trebuie să conducă la prevederea unui singur punct de intrare şi a unui
singur punct de ieşire pentru fiecare funcŃiei.
j) Analiza trebuie să se desfăşoare în mod exhaustiv numai după considerente
funcŃionale, astfel ca nivel cu nivel să se definească subfuncŃii omogene din
punct de vedere al gradului de abstractizare şi nu al datelor sau al resurselor
utilizate.
În concluzie, analiza unei funcŃii date în contextul acestei tehnici este un proces de
decompoziŃie funcŃională, în care trecerea de la un anumit nivel la cel inferior lui se face prin
utilizarea principiilor prezentate anterior.
Analiza prin decompoziŃie funcŃională presupune multă inventivitate şi se bazează pe
o experienŃă acumulată în timp.
Proiectantul construieşte o tabelă de intrări/ieşiri pentru un anumit modul, numai după
ce au fost analizate toate funcŃiile subordonate funcŃiei reprezentate prin acel modul.
În construirea tabelei corespunzătoare unei scheme de structură funcŃională se aplică
atât metoda top-down cât şi metoda bottom-up, iar pentru proiectarea structurată e preferabilă
metoda top-down.
Tabela de intrări/ieşiri are forma literei T, în partea stângă se reprezintă intrările în
modul, iar în dreapta ieşirile din modul. Numărul de intrări poate fi mai mare, mai mic sau
egal cu numărul de ieşiri, sau poate fi chiar zero.
Datele, ca mijloc de realizare a legăturilor dintre modulele schemei de structură, pot
avea unul din următoarele roluri în raport cu un anumit modul analizat, astfel [21]:
• control, care realizează selectarea funcŃiilor care se execută
• prelucrarea, care participă la prelucrări sau crearea unei date de ieşire dorită
• transfer, ce arată datele ce trec prin modul fără a-şi schimba identitatea şi
valoarea
• modificată, ce este rezultatul funcŃiilor de prelucrare din modul
80
Scopul şi fazele de realizare a analizei
Forma şi conŃinutul tabelului este redată mai jos:
Modulul ---------------
FuncŃia -----------------
Intrări Ieşiri
Identificare Identificare
Tip Sursă Tip DestinaŃie
Intrare Ieşire
Pentru obŃinerea unor tabele consistente, o atenŃie deosebită trebuie acordată modului
de identificare a datelor şi a rolului pe care-l joacă fiecare dată în modulele unde este utilizată.
Tehnica are limite legate de faptul că nu dă nici o indicaŃie relativă la modul de
structurare a datelor, ea punând accent numai pe fluxul datelor.
Această metodă de stabilire a informaŃiilor de intrare pe baza celor de ieşire este foarte
utilă îndeosebi la sistemele complexe, care vehiculează multe informaŃii. Ea este uşor de
aplicat şi permite nu numai identificare informaŃiilor de intrare ci şi a procedurilor sau
operaŃiilor din aceste proceduri.
Abordarea ei este făcută plecând de la intrări şi ajungând la ieşirile sistemului
informatic, permiŃând identificarea tuturor informaŃiilor primare din sistem şi legăturilor
logice dintre acestea.
Are dezavantajul că nu este posibilă punerea în evidenŃă a tuturor legăturilor dintre
datele primare existente în sistem, fapt ce la un moment dat generează neajunsul că nu se pot
obŃine anumite date de ieşire.
Ea are ca scop efectuarea unei analize complexe asupra activităŃilor şi fluxurilor
informaŃionale existente, a ariei de cuprindere a sistemului informatic şi al dotării cu tehnică
de calcul, pentru evidenŃierea calităŃii, limitelor şi deficienŃelor actualului sistem în vederea
stabilirii cerinŃelor generale ce vor fi asigurate prin intermediul unui nou sistem informatic ce
se va proiecta pe baza unor variante de realizare.
Această etapă a proiectării sistemelor informatice grupează un ansamblu de faze ce
trebuie să răspundă unei cerinŃe ca [21]:
• stabilirea ariei de cuprindere a sistemului informatic existent, ce va deveni
sistem obiect, pentru conceperea şi realizarea unui nou sistem informatic
• reflectarea activităŃilor şi operaŃiilor economice specifice sistemului informatic
actual
• surprinderea modificărilor ce se impun în organizarea şi funcŃionarea
sistemului informatic în viziunea conceperii şi realizării unui nou sistem
informatic
• evidenŃierea dotării actuale cu tehnică de calcul prin prisma concordanŃei
dintre sistemele electronice de calcul şi viitorul sistem proiectat, inclusiv
identificarea problemelor ce urmează a fi rezolvate de noul sistem informatic
cu ajutorul calculatorului
• stabilirea unei soluŃii de principiu care să precizeze activităŃile şi operaŃiile ce
urmează a fi informatizate în plus faŃă de actualul sistem, costul antecalculat al
sistemului, tipul de calculator utilizat, sistemul de operare aferent, inclusiv
soluŃia de gestiune a datelor pe care se bazează conceperea şi realizarea noului
sistem, implicaŃiile de organizare internă a unităŃii, precum şi planificarea
realizării noului sistem informatic
81
3.2. Modelarea logică şi diagramele fluxurilor de date

Logica poate avea două semnificaŃii şi anume: prima ne trimite la faptul că acŃiunea se
bazează pe anumite reguli de judecată, adică anumite concepte, iar a doua se referă la
descrierea unui fenomen, proces, obiect, etc., astfel ca el să fie înŃeles.
Toate metodologiile existente apelează la operaŃia de modelare logică a datelor şi a
prelucrărilor sub formă de diagrame, iar diferenŃele constau în folosirea pronunŃată a
diagramelor pentru descrierea sistemului, putându-l încadra în diagrame de context, diagrame
pentru fluxurile de date fizice şi diagrame ale fluxurilor de date logice, iar altele apelează la
combinaŃii de diagrame, tabele şi forme descriptive.
Diagramele de context ne reliefează aria de întindere a sistemului analizat, prin
specificarea elementelor din interiorul firmei şi a celor externe sub numele de entităŃi externe,
fată de sistemul analizat.
Diagramele fluxurilor de date ale sistemului fizic curent specifică persoanele şi
tehnologiile folosite de fiecare proces de transfer şi transferare a datelor, acceptându-se unele
intrări şi descrie ieşirile din procesele amintite.
Diagramele fluxurilor de date ale sistemului logic curent sunt independent de
tehnologie, reliefând funcŃiile de prelucrarea datelor executate de sistemul curent.
Diagramele fluxurilor de date ale sistemului logic nou prezintă circuitul datelor,
structura lor şi cerinŃele funcŃionale ale noului sistem.
Descrieri ale obiectelor diagramelor fluxurilor de date se găsesc în dicŃionarele
proiectate sau depozite CASE (repository). Acestea în literatura de specialitate sunt denumite
generic ca diagrame ale fluxurilor de date (DFD).
DFD -ul are ca obiectiv urmărirea modului de transferare a datelor între procesele de
prelucrare, aceste diagrame se mai numesc modele ale proceselor de prelucrare, iar operaŃia
se numeşte modelarea proceselor. DFD-ul este una din tehnicile analizei structurate şi au un
puternic impact asupra proceselor de dezvoltare a sistemelor.
Redarea proceselor de prelucrare cu diagramele fluxurilor de date primeşte noi
accepŃiuni prin încorporarea ei în instrumentele de analiză şi proiectare cu ajutorul
calculatorului, adică folosirea produselor CASE, ce duce la complicarea unor probleme.
PiaŃa are zeci de produse CASE şi toate pun în practică rezultatele cercetării
fundamentale, de aceea utilizatorii CASE sunt puşi într-o mare dificultate, fiind-că ei apelează
la metode diferite, cel puŃin ca nume.
Important este să nu uităm scopul DFD pentru a produce linişte potenŃialilor
beneficiari, că produsele CASE care se respectă oferă posibilitatea de alegere a tehnicilor
(metodelor) utilizate pentru prezentarea DFD.
Majoritatea produselor apelează tehnici de redare a DFD, ca: Gane&Sarson şi
Yourdon&DeMarco. Acestea sunt asemănătoare, iar diferenŃele dintre ele le vom prezenta.
3.2.1. Tehnica Gane&Sarson

Scopul DFD la o anumită componentă organizatorică sau funcŃională la care se referă
este de a arăta următoarele aspecte [44]:
• sursa datelor prelucrate
• operaŃiile de prelucrare prin care trec datele
• destinaŃia datelor prelucrate
• legătura existentă între prelucrări şi activitatea de stocare a datelor
Tehnica DFD apelează la patru simboluri de bază pentru reprezentarea sistemelor
informatice logice cât şi sistemele fizice înlocuind “clasicele” scheme logice. Se folosesc
următoarele simboluri:
82
Modelarea logică şi diagramele fluxurilor de date
- Entitate externă:
- Flux de date:
sau
- Loc de stocare:
- Proces de prelucrare:
Schemele de sistem ce prezintă configuraŃia fizică a sistemului informatic sunt mai

sugestive decât o diagramă, dar pentru alte cazuri sunt mai sugestive DFD -urile, mai ales
pentru reprezentarea logicii sistemelor informaŃionale.
Exemplu de DFD pentru ClienŃii unei firme:
D1 PRODUSE
1
Comenzi
CLIENłI Prelucrare
Vânzare comenzi
D2 VÂNZĂRI
Figura 3.1 Fluxul datelor pentru relaŃiile cu clienŃii [21]

Diagrama scoate în evidenŃă actul de vânzare-cumpărare, din care reiese că un client
pentru a beneficia de produsele altei firme trebuie să lanseze o comandă, iar vânzarea să aibă
loc este necesară existenŃa produselor solicitate.
Clientul este o entitate externă care este obiectul studiului nostru.
Prelucrarea (1) dă răspuns comenzii de vânzare prin apelarea informaŃiilor existente
în colecŃia de date Produse (D1) şi actualizează datele despre vânzare în colecŃia de date
Vânzări (D2).
DFD -ul stabileşte aria de cuprindere a sistemului luat în studiu şi zonele de la
beneficiarul implicat în operaŃiunile de prelucrare a datelor. El nu are un caracter tehnic,
deoarece simbolurile folosite sunt uşor de înŃeles şi utilizat. DFD -ul prezintă atât datele
stocate în sistem cât şi procesele de prelucrare prin care trec acestea, arătând relaŃiile externe
între datele sistemului şi procesele de prelucrare.
3.2.1.1. Simbolurile utilizate pentru DFD de această metodă

a) EntităŃile externe (EE) sunt denumite sursă/destinaŃie sau agenŃi externi.
Simbolul folosit de această metodă este un pătrat cu latura stângă şi superioară
umbrite, astfel:
Uneori sunt însoŃite de litere ce au rol de identificator.
83
EntităŃile externe sunt surse şi/sau destinaŃie ale fluxurilor de date în şi din sistem. Ele pot fi
reprezentări ale grupurilor de persoane, ca: clienŃi, furnizori, alte sisteme.
Pe timpul realizării DFD -urilor, ca să prevenim realizarea unor linii de flux prea lungi
şi intersectate se pot folosi două sau mai multe simboluri pentru aceeaşi entitate pe aceeaşi
pagină. În acest caz se foloseşte o diagonală în colŃul din dreapta jos, arătând că entitatea este
de mai multe ori în acest flux, de exemplu:
F
Furnizor Numărul din triunghi ne arată de câte ori apare
2 în flux entitatea Furnizori
b) Fluxuri de date, aici săgeata sugerează calea pe care pot suprapune una sau mai
multe structuri de date, în momente nespecificate. Fiecare săgeată a fluxului primeşte un
nume ce descrie numai structura de date, avem situaŃii când se impune prezentarea mai multor
structuri de date pe o singură săgeată de flux, de exemplu:
Istoric Flux multiplu

Restaurare Descriere
istoric Vânzări şi plăŃi clienŃi
Produsele CASE oferă posibilitatea asocierii structurilor multiple de date unei singure
săgeŃi de flux, în timp ce altele nu permit astfel de operaŃii.
La intersecŃia fluxurilor fără contopire se poate folosi bucla sau linia întreruptă, astfel:
buclă întrerupere
c) Stocarea datelor, foloseşte ca simbol un dreptunghi alungit, astfel:
F1 Furnizori
La stânga dreptunghiului alungit se poate plasa un triunghi unde se va specifica

numărul de apariŃii aceluiaşi simbol, astfel:
4 F1 Furnizori
d) Argumente de căutare, în timpul prelucrărilor dintr-un loc de stocare a datelor sunt

necesare operaŃii de ordonare a datelor în funcŃie de o condiŃie a utilizatorului, după
care se poate face căutarea în funcŃie de condiŃia pusă. Cel mai important este ca
proiectanŃii să cunoască toate argumentele de căutare ce se folosesc ulterior. Exemplu:
F Furnizori
F-COD = “F121”
Raportări
Furnizori
e) Locuri de stocare cu o singură intrare şi ieşire
84
Modelarea logică şi diagramele fluxurilor de date
DFD -ul are un simbol de redare a operaŃiunii de stocare cu o singură intrare şi ieşire,
ce duce la examinarea mai atentă, pentru a se trage concluzia dacă acel loc din punct de
vedere economic, logic este necesar. PrezenŃa acestuia poate sugera un fişier temporar fizic,
ce este folosit cu funcŃia esenŃială de mediu de comunicare a datelor. Spre exemplu:
Validare Validare
clienŃi clienŃi
D1 Date cu rău platnici
f) Procesul de prelucrare este o funcŃie executată scopul transferării datelor,

reprezentat printr-un dreptunghi cu colŃuri rotunjite, ca de exemplu:
identificator
Verb + descrierea obiectului funcŃie
(opŃional) implementare fizică – numele

sistemului
Identificatorul ce prezintă un număr de identificare a procesului de prelucrare.
Partea inferioară, opŃional, poate conŃine un component funcŃional, nume de program
sau alt element ce participă fizic la realizarea procesului respectiv.
Se recomandă ca erorile sau excepŃiile să nu fie tratate în diagrama fluxului de date,
mai ales pentru cele ample.
Obiectul DFD -ului este de a reliefa fluxul normal de date, iar erorile şi excepŃiile pot
fi descrise ulterior prin procedee specifice produselor CASE.
Datele descrise sunt memorate într-un loc special numit depozit (repository).
3.2.1.2. Sintaxa DFD -ului şi produsele CASE

Produsele CASE oferă beneficiarului un sistem iterativ de lucru, cu mesaje ajutătoare
în cazul că se încearcă introducerea unei construcŃii eronate într-un DFD sau sistemul refuză
acceptarea introducerii obiectului.
Reguli sintactice de verificare cu ajutorul softului:
• au toate obiectele câte un identificator?
• au toate obiectele şi fluxurile de date câte un nume?
• au toate procesele cel puŃin câte un flux de intrare şi cel puŃin un flux de date
ieşire?
• fiecare flux de date are legătură cu un proces?
• au toate fluxurile de date sensul marcat prin săgeată?
Reguli sintactice ce nu pot fi verificate uşor cu softul: au fluxurile de date un nume
semnificativ? au toate procesele din diagramă un descriptor de forma “verb + substantiv-
obiect-al-prelucrării”? locurile de stocare reprezintă obiecte, fenomene sau evenimente de
interes? există locuri de stocare ce să aibă o singură intrare şi o ieşire ce sunt fişiere
intermediare fizice temporare? se menŃine un control minim de multiplicare al simbolurilor,
astfel ca numărul lor să ducă la intersectări ce să creeze neâŃelegeri?
85
3.2.2. Tehnica Yourdon & DeMarco

Aceasta utilizează următoarele simboluri:
Entitate externă
Flux de date (poate avea şi alte forme)
Loc de stocare
Proces de prelucrare
Această tehnică sugerează că demersul de creare a diagramelor unui sistem trebuie să

înceapă cu o diagramă de context, prin care să fie prezentate entităŃile externe, intrări şi ieşiri
în/din sistemul analizat.
Literatura de specialitate ne recomandă că nici o diagramă să nu cuprindă mai mult de
7 (şapte) procese de prelucrare.
Un sistem mare trebuie să fie reprezentat printr-un set de diagrame, care pot să fie:
• o diagramă de context;
• o diagramă de nivel 0 ce arată subsistemele sistemului;
• până la 7 (şapte) diagrame nivelul 1 ce prezintă principalele aplicaŃii ale
fiecărui subsistem;
• până la 49 diagrame de nivel 2 ce arată detaliile fiecărei aplicaŃii;
Este recomandabil ca aplicaŃiile să fie exploatate pe această cale până la detaliile
logice ale procesului.
Exemplu o diagramă de context pentru vânzare - cumpărare:
CLIENłI
Comenzi vânzare
Documente Comenzi aprovizionare
BANCĂ de decontare Furnizor
FURNIZOR
InformaŃii de aprovizionare
Date vânzare
MANAGERI
Figura 3.2 Prelucrarea stocurilor de vânzare şi cumpărare
3.3. DiferenŃele de modelare logică între cele două tehnici

DiferenŃa esenŃială este că simbolurile folosite nu sunt identice, dar mai există încă trei
diferenŃe importante şi anume: metoda folosită la descompunerea diagramelor, modelarea
sistemului curent, relaŃia dintre diagrama fluxurilor de date şi modelul datelor.
86
DiferenŃele de modelare logică între cele două tehnici
3.3.1. Modelarea sistemului curent

Trecerea de la vechiul sistem la unul nou, ne va obliga să decidem asupra datelor şi
procedurilor ce duc la obligativitatea construirii modelului logic al noului sistem, care poate
să conŃină una sau mai multe DFD, un model de date şi logica procesului de prelucrare.
Una din modalităŃi este prezentarea detaliată a sistemului curent, apoi se va continua
cu proiectarea modelului logic, prin abstractizarea celui existent. După care se scoate în
evidenŃă ce trebuie schimbat din actualul sistem şi ce să realizeze noul sistem. SecvenŃial
procesul se realizează conform figurii 3.3.
Sistem
nou
Cum e influenŃat noul
sistem de modelul
logic propus?
Modelul logic
propus
Cum se poate schimba
sistemul curent?
Modelul
logic curent
Cum se poate reda modelul
logic curent?
Sistem
curent
Figura 3.3 Modelul pentru varianta Yourdod&DeMarco [21]
Gane şi Sarson adoptă o variantă mai categorică, pornind de la întrebarea: “Ce trebuie
să facă noul sistem?”. El se poate reda schematic pentru sistemul propus conform figurii 3.4.
Care
e calea cea scurtă
de continuare a modelului
propus?
Modelul Structura cerinŃelor

logic curent utilizatorului
Modelul
logic propus
Sistemul
Propus
Figura 3.4 Varianta de modelare Gane&Sarson
87
Sintetic reiese că varianta Yourdon&DeMarco redă procesul de analiză prin 7(şapte)

paşi, iar varianta Gane&Sarson în 5(cinci) paşi.
Varianta DeMarco are paşii [21]:
1. Construirea modelului curent. 2. Construirea modelului logic curent pe baza
modelului fizic anterior.3. Construirea modelului logic al noului sistem şi
crearea unei specificaŃii structurate constând în DFD, dicŃionare de date şi
specificaŃii ale proceselor. 4. Crearea unei familii de modele noi. 5. Costul
realizării şi timpul estimat pentru fiecare model. 6. Alegerea unui model. 7.
Gruparea specificaŃiilor pe subsisteme.
Varianta Gane are paşii [21]:
1. Construirea modelului logic curent. 2. Crearea modelului logic al noului
sistem. Crearea unei specificaŃii structurate constând în DFD, dicŃionare de
date şi specificaŃii ale proceselor. Construirea modelului de date, cu
exprimarea conŃinutului datelor stocate. 3. Proiectarea unei baze de date. 4.
Crearea unui nou model fizic al sistemului. 5. Gruparea specificaŃiilor pe
subsisteme.
DiferenŃa majoră este că cele două variante includ un pas referitor la modelarea
datelor, prin care sunt definite cu atenŃie conŃinuturile de stocare din DFD, cel puŃin în cea de-
a treia formă normalizată.
3.3.2. RelaŃiile existente între DFD şi modelul datelor.

Fiecare săgeată din DFD reprezintă un flux de date, în sensul unui traseu pe care
structurile datelor elementare sau grupate se vor deplasa în, prin şi din.
DeMarco apelează la convenŃii speciale pentru descrierea datelor, permiŃând scoaterea
în evidenŃă a repetiŃiilor sau a construcŃiilor opŃionale. Folosindu-se parantezele rotunde ( ),
pentru a sugera construcŃiile opŃionale şi acoladele { }, pentru repartiŃii.
Gane recomandă în plus ca structurile de date să fie reduse la a treia formă
normalizată, iar conŃinutul locurilor de stocare a datelor să fie prezentat prin reducere la unul
sau mai multe tabele relaŃionale în forma treia normalizată.
3.4. Feluri ale diagramelor fluxurilor de date
3.4.1. Diagrama de context

Aceasta este diagrama de nivelul cel mai înalt al sistemului informaŃional, prin care se
descriu fluxuri de date în şi din sistem, din şi spre entităŃile externe. Ca de exemplu :
BANCĂ Plată
Proces de
încasare Încasare
FURNIZOR
Figura 3.5 Exemplu pentru diagrama de context

Cercul diagramei de context defineşte graniŃele sistemului. GraniŃa reprezintă locul de
separare a sistemului studiat de mediul să extern. Mediul fiind tot ce înconjoară sistemul,
entităŃile diagramei fiind cele mai relevante elemente pentru specificarea mediului extern.
88
Feluri ale diagramelor fluxurilor de date
Conceptul de interfaŃă, este un flux de legături a sistemului său, existând interfeŃe ca

legăturile între componentele sistemului.
3.4.1. Diagrama fluxurilor de date fizice (DFDF)

Ea reprezintă schematic sistemul prin scoaterea în evidenŃă a entităŃilor interne şi
externe ale sistemului, precum şi fluxurile datelor în şi din aceste entităŃi.
DFDF -ul specifică unde, cum şi de cine este realizat acest proces al sistemului şi va
scoate în relief ce este realizat. Exemplu în figura următoare:
CUMPĂRĂTOR Bani
1.0
Vânzător
Borderouri Bani şi bandă casă
3.0 Bandă de casă verificată 2.0
Contabilitate Caserie
Foaie de depunere şi bani

Jurnal – Vânzări BANCĂ
Figura 3.6 Exemplu pentru diagrama fluxurilor de date fizice
Casetele pătrate ale diagramei definesc entităŃile externe mediului relevant, iar
cercurile definesc entităŃile interne.
3.4.2. Diagrama fluxurilor de date logice (DFDL)

Ea este reprezentarea simbolizată a unui sistem, prin care, prin care se evidenŃiază
procesele sistemului, precum şi intrările sau ieşirile de date în/din proces. Aceasta reprezintă
natura logică a sistemului, ce activităŃi efectuează sistemul, fără să specifice cum, unde sau
de către cine sunt executate aceste activităŃi.
Avantajul DFDL -ului faŃă de DFD este acela că putem reliefa funcŃiile executate de
sistem. Un exemplu în figura următoare:
Cumpărător Plată
1.0
Încasat
2.0
Compară bandă
4.0 cu banii
Înregistrare Validare încasări
Vânzare
3.0
3.0 Pregătire
Preg ătire depunere
depunere
Jurnal - Vânzări
Depunere
BANCĂ
Figura 3.7 Exemplu pentru diagrama fluxurilor de date logice
89
Din figură reiese că etichetele de pe fluxurile de date arată natura datelor şi nu cum
sunt transmise acestea. Se poate observa că fiecare dintre sensurile fluxurilor de date spre sau
din, are sensurile spre şi din.
Dacă două diagrame ale fluxurilor de date, diagrama de context şi nivelul 0, au fluxuri
de date externe echivalente, se spune despre ele că sunt diagrame ale fluxurilor balansate.
Descompunerea descendentă sau de sus în jos este asociată cu metoda sistemelor, care
este o modalitate de concepte a soluŃiilor problemelor şi de proiectare a sistemelor
informatice. Metoda sistemelor cere ca sistemul să fie văzut ca un întreg ce cuprinde mai
multe componente aflate în strânsă legătură între ele cu o astfel de metodă, analizăm un
sistem sau o problemă prin descompunerea lor de sus în jos, arătând astfel mai multe detalii.
3.4.3. Utilizarea DFD -lui în procesul de analiză

Aspectele importante de care trebuie să Ńinem seama în timpul analizei sunt:
Completitudinea, ce se referă la urmărirea includerii în DFD a tuturor componentelor
sistemului analizat. Aici se va urmări dacă DFD-ul conŃine [32]:
• fluxurile datelor ce nu au finalitate
• locurile de stocare a datelor, procese sau entităŃi externe ce au rămas nelegate
de altceva
Stările fac ca diagramele să fie eronate sau incomplete. Pentru produsele CASE,
depozitul e legat de diagramă, ceea ce arată că pentru orice simbol al diagramei, care se va
crea automat o poziŃiei în depozit, poziŃie ce se va completa de analist.
CosistenŃa, face trimiterea la verificarea compatibilităŃii între descrierea sistemului de
pe un anumit nivel şi descrierea superioară sau descrierea inferioară.
Factorul timp, aici DFD -ul nu scoate în evidenŃă factorul timp. Deci timpul poate fi
evidenŃiat prin diagramele setărilor de tranziŃie.
Dezvoltarea iterativă, deci un lucru dorit nu iese întotdeauna de la prima încercare.
EvidenŃiindu-se faptul că determinarea cerinŃelor sistemului, structurarea lui, nu sunt operaŃii
secvenŃiale ale analizei din cadrul ciclului de viaŃă a sistemului, ci sunt procese iterative.
Primitivele diagramelor fluxurilor de date. Aici procesul trebuie să înceteze atunci
când s-a atins nivelul cel mai de jos, ceea ce nu este uşor de controlat. Avem reguli de
determinare a momentului încetării procesului de descompunere şi acestea sunt:
• dacă întregul proces se reduce la o singură decizie sau formulă de calcul, sau o
singură operaŃie specifică bazelor de date
• dacă locul de stocare este o singură entitate
• dacă beneficiarii sistemului apreciază că nu au nevoie de detalii mai multe sau
când analiştii consideră că au oferit suficiente amănunte
• dacă fluxul de date nu mai trebuie să fie descompus pentru a se arăta că unele
date li se aplică un tratament, iar pentru altele sunt diferite
• dacă se consideră că analistul a scos în relief fiecare formulă, tranzacŃie, ecran
calculator, raport, etc…
• dacă analistul apreciază că s-a atins cel mai de sus nivel al procesului de
descompunere a opŃiunilor meniurilor sistemului şi pentru fiecare din ele este
câte un proces distinct
Prezentările făcute arată că procesul de descompunere este destul de subiectiv şi el
poate începe în orice moment, cu intenŃia de stopare definitivă, dar poate fi şi reluat ulterior,
dacă se consideră utilă descompunerea.
O concluzie, se poate afirma că diagramele fluxurilor de date reprezintă instrumente
lejere de modelare a proceselor, dar şi pentru modelarea sistemelor fizice şi logice curente şi
chiar pentru cele noi.
90
Analiza orientată obiect (AOO)
DFD -ul se utilizează la procesele de analiză a decalajelor prin care analistul poate
stabili diferenŃele dintre două sau mai multe seturi de diagrame ale fluxurilor de date,
reprezentând două sau mai multe stări ale sistemului sau discrepanŃele într-o singură DFD.
DFD -urile pot reliefa următoarele aspecte [1] [7]:
• fluxurile de date redundante, apărute, de regulă prin apelarea la nume diferite
ale aceloraşi date
• date ce intră în prelucrări, ele nu sunt folosite
• date ce sunt actualizate în mai multe locuri
Instrumentele CASE dau posibilitatea obŃinerii mai multor elemente despre DFD,
după performanŃele pachetului program folosit.
3.5. Analiza orientată obiect (AOO)

Analiza orientată obiect (AOO) este o tehnică de specificaŃii semiformală pentru
paradigma orientată obiect. S-a arătat în capitolul anterior că există un număr de tehnici
diferite pentru analiza sistemelor structurate care sunt echivalente în esenŃă. Similar, există în
mod curent peste 50 de tehnici diferite pentru executarea AOO şi încă mai apar noi tehnici.
Din nou aceste tehnici sunt aproape echivalente.
Pentru că AOO este o tehnică semiformală, o parte intrinsecă a fiecărei tehnici pentru
analiza orientată obiect este notaŃia grafică asociată. Astfel, învăŃarea folosirii tehnicii
specifice presupune învăŃarea principalelor notaŃii grafice. Aceasta s-a schimbat o dată cu
publicarea UML (Unified Modeling Language-limbaj de modelare generalizat). În această
carte, UML este folosit pentru reprezentarea atât a AOO, cât şi a designului orientat obiect.
Pentru mai multe informaŃii despre UML vezi capitolul 6.
Până la scrierea cărŃii, nici o tehnică sau metodologie n-a fost ataşată la UML doar
echipa de la Rational. UML rămâne o notaŃie comună ce poate fi folosită de orice tehnică de
modelare şi de aceea cu orice metodologie.
AOO constă din 3 paşi [44]:
1. Modelarea use-case. Se determină modul în care rezultate variate sunt calculate de
produs (fără referire la secvenŃe). Prezentăm această informaŃie în forma diagramei
use-case şi scenariilor asociate. Acest pas, numit câteodată şi modelarea funcŃională,
este orientat mai ales pe acŃiune.
2. Modelarea clasei. Se determină clasele şi atributele acestora. Apoi determinăm
iteraŃiile dintre clase. Prezentăm această informaŃie în forma unei diagrame
aproximativ similară cu cea relaŃie-entitate şi pe care o numim diagrama clasei. (Unii
autori se referă la această diagramă cu numele de modelul clasei). Acest pas este
orientat numai pe date.
3. Modelarea dinamică. Se determină acŃiunile executate de fiecare clasă sau care se
aplică fiecărei clase şi subclase. Această informaŃie apare în formă de diagramă
aproximativ similară cu cea a maşinii cu stare finită numită diagrama de stare. Acest
pas este orientat numai pe acŃiune.
În practică, cei 3 paşi nu se execută pur secvenŃial. O schimbare într-o diagramă va
declanşa revederi corespunzătoare ale celorlalte 2 diagrame. Astfel, cei 3 paşi ai AOO sunt
executaŃi practic în paralel. Aceasta are sens în viziunea faptului că în paradigma orientată
obiect nici datele (Pasul 2) nici acŃiunile (Pasul 1 şi 3) nu au prioritate una asupra celeilalte.
AOO nu trebuie cu siguranŃă văzut ca o combinaŃie a 2 din tehnicile de specificaŃii
structurate din capitolul anterior şi anume modelarea relaŃie-entitate (ERM) şi maşini cu stare
finită (FSM). Din contră, AOO este o tehnică de modelare ce foloseşte diagrame pentru a
specifica rezultatele celor 3 paşi de modelare. În loc să inventeze căi complet noi de afişare a
91
acestei informaŃii, mai bine se folosesc notaŃii bazate pe tehnici structurate larg utilizate (vezi
capitolul 5).
O altă cale de a privi este aprecierea faptului că Ńinta lui AOO ca şi a celorlalte tehnici
de specificaŃii este a specifica produsul final ce urmează a fi construit. Două aspecte critice
ale produsului sunt datele şi acŃiunile acestuia. AOO foloseşte o varietate de tehnici de
modelare pentru a înŃelege datele, acŃiunile şi interacŃiunile între date şi acŃiuni. În timpul
cursului de analiză, cunoştinŃele acumulate despre produs sunt reprezentate în mai multe
feluri, fiecare reflectând un alt aspect al produsului final. Diagramele sunt în mod continuu
actualizate pe măsură ce apar noi percepŃii despre cum va fi modelat sistemul. La sfârşitul
fazei AOO, punctele de vedere combinate oferă o înŃelegere completă a produsului, care ar fi
greu de obŃinut dacă ar fi fost folosită doar o singură tehnică de modelare.
Deci vom prezenta în continuare cum se face analiza sistemului existent.
Analiza sistemului existent este necesară la fundamentarea direcŃiilor de perfecŃionare
a sistemului informatic existent şi înlocuirea acestuia cu un sistem nou ce va satisface toate
cerinŃele informaŃionale ale conducerii unităŃii şi a compartimentelor funcŃionale.
Ea se poate realiza cu ajutorul unor faze ca [44]:
a) Conducerea şi organizarea analizei, ce se realizează prin:
• pregătirea condiŃiilor necesare analizei sistemului informatic existent
• constituirea colectivului de analiză a sistemului informatic existent
• elaborarea planului de realizare a analizei
b) Realizarea analizei sistemului existent, ce se realizează prin:
• documentarea pentru analiza sistemului existent
• alegerea procedeelor de analiză a sistemului existent
• studiul componentelor sistemului existent
• evaluarea critică a sistemului informatic existent
• elaborarea variantelor de realizare a noului sistem informatic.
c) Finalizarea analizei sistemului existent, se realizează prin:
• definitivarea documentaŃiei necesare
• avizarea etapei de către conducerea unităŃii economice beneficiare
3.6. Faza de organizare şi conducere a analizei sistemului existent

Deoarece această fază se subdivide în trei subfaze, acestea vor fi prezentate în detaliu.
3.6.1. Pregătirea condiŃiilor necesare analizei sistemului existent

În declanşarea analizei sistemului existent, iniŃiativa este de partea conducerii unităŃii
beneficiare ce specifică tema şi obiectivele analizei în “Nota de comandă”.
Aceasta va conŃine denumirea temei şi a sferei de cuprindere precum şi consideraŃiile
generale ce impun perfecŃionarea sistemului existent şi eventual proiectarea unui nou sistem
informatic ce se foloseşte de facilităŃile bazelor de date.
Pe baza acestei note se încheie “Contractul de execuŃie” pentru analiza sistemului
informatic existent, între unitatea beneficiară şi unitatea de proiectare a noului sistem.
La stabilirea valorii contractului se vor avea în vedere: orele planificate pentru analiză,
personalul implicat, tarifele de realizare, termene de execuŃie, inclusiv obligaŃiile părŃilor
contractante şi modul de decontare a execuŃiei.
92
Faza realizării analizei sistemului existent
3.6.2. Constituirea colectivului de analiză a sistemului existent

Acest colectiv poate fi alcătuit din personalul propriu al unităŃii beneficiare sau din
personalul unei unităŃi specializate în proiectarea sistemelor informatice cu baze de date, sau
mixt (o parte din personal propriu şi o altă parte din personal al unităŃilor specializate).
Varianta cu personalul propriu are avantajul cunoaşterii tematicii sistemului
informatic existent, ce asigură realizarea unei analize de calitate într-un termen foarte scurt.
Ea are dezavantajul că membrii săi nu pot sesiza toate deficienŃele şi limitele reale ale
sistemului existent deoarece sunt obişnuiŃi cu structura şi funcŃionarea sistemului.
Varianta cu personal de specialitate are avantajul că aceştia cunosc deficienŃele şi
limitele altor sisteme similare cu cel analizat, dar are dezavantajul realizării acestei analize
într-un timp mai mare, deoarece este impusă cunoaşterea detaliată a unor anumite părŃi cu
caracter specific, de foarte multe ori de unicat, ale sistemului informatic existent.
Varianta mixtă este cel mai des utilizată datorită maximizării avantajelor şi
minimizării dezavantajelor celor două variante menŃionate anterior.
Indiferent de componenŃa colectivului, din el trebuie să facă parte conducătorii
compartimentelor funcŃionale supuse analizei şi specialiştii ce cunosc activităŃile desfăşurate
în sistemul informatic existent. Conducătorii compartimentelor sunt necesari pentru
identificarea informaŃiilor utile, eliminarea celor de prisos, inclusiv pentru formularea
cerinŃelor informaŃionale pentru noul sistem informatic. Specialiştii sunt necesari deoarece
cunosc detailat activităŃile şi operaŃiile desfăşurate în actualul sistem şi ajută la sesizarea
neajunsurilor segmentului din sistemul informatic de care răspunde.
Mărimea colectivului este în funcŃie de obiectivele analizei, sfera de cuprindere,
complexitatea sistemului existent şi particularităŃile sale, inclusiv termenele de realizare.
Urmărirea realizării analizei este făcută la finalizarea fiecărei faze parcurse, cu ajutorul unui
colectiv tehnic de avizare ce este format din reprezentanŃii unităŃii beneficiare şi a celei de
proiectare în concordanŃă cu condiŃiile contractuale dintre părŃi.
3.6.3. Elaborarea planului de realizare a analizei

Activitatea de analiză se desfăşoară pe baza unui plan de muncă, prin care se
urmăreşte folosirea cât mai raŃională a personalului, termenilor intermediare şi finale precum
şi a procedurilor de control şi avizarea realizării analizei sistemului informatic existent.
Această planificare se poate face cu ajutorul graficului de tip PERT, iar urmărirea sa operativă
cu ajutorul graficelor de tip GANTT.
3.7. Faza realizării analizei sistemului existent

Deoarece această fază se împarte în subfaze, se vor prezenta detailat părŃile
componente.
3.7.1. Documentarea pentru analiza sistemului existent

Aceasta presupune studiul unor probleme de organizare a unităŃii, a particularităŃilor
procesului tehnologic, a fluxurilor informaŃionale şi a activităŃilor desfăşurate, precum şi
cadrul legislativ - normativ care reglementează funcŃionarea sistemului informatic. Conform
acestei, se va studia modul de organizare şi conducere a unităŃii, activităŃii de bază,
particularităŃile procesului tehnologic, strategia şi tactica conducerii în realizarea sarcinilor de
producŃie, principalele opŃiuni pentru dezvoltarea unităŃii, activităŃilor desfăşurate,
documentele folosite, compartimentele implicate, frecvenŃele şi termenele de realizare a
93
activităŃilor, studiul volumului documentelor utilizate şi a sistemului de codificare a datelor

etc. Paralel se va studia dotarea cu tehnică de calcul şi posibilităŃile de extindere a acesteia
pentru asimilarea unui nou sistem informatic. Mai trebuie studiate legile, hotărârile, decretele,
normativele, instrucŃiunile ce reglementează activitatea fiecărui compartiment al unităŃii şi
modul de respectare a cadrului legislativ de compartimentele funcŃionale ale unităŃii
beneficiare. În documentare trebuie să avem în vedere cele mai noi realizări ale organizării şi
funcŃionării sistemelor informaŃionale, precum şi diversele sisteme informatice aplicate în
unităŃi economice similare.
3.7.2. Alegerea procedeelor de analiză a sistemului existent

Aceasta se face în funcŃie de complexitatea şi particularităŃile sistemului informaŃional
existent, aria de cuprindere a acestuia, condiŃiile concrete de lucru şi experienŃa personalului
care realizează analiza.
În literatura de specialitate, procedeele de analiză a sistemului existent, sunt foarte
diversificate şi urmează a fi utilizate în raport cu condiŃiile concrete de desfăşurare a analizei,
dintre care unele le vom menŃiona în cele ce urmează.
3.7.2.1. Interviul
El este procesul comunicării diadice, de stabilire a unei relaŃii cu o finalitate precisă,
predeterminată, proces conceput pe alternanŃa rolurilor şi care implică formulări de întrebări şi
orientări de răspunsuri.
Cuvântul proces arată dinamismul, interacŃiune continuă, cu multe variabile de lucru,
cu acŃiune înlănŃuită după un anumit sistem de derulare.
Cuvântul diadic, pornind de la diadă se scoate în relief faptul că interviul este o
interacŃiune persoană cu persoană, între două părŃi sau două componente, deoarece pot fi mai
multe persoane, dar niciodată mai mult de două păŃi, ceea ce ia interviul şi ce intervievată.
Cuvântul relaŃii sugerează o relaŃie interpersonală între părŃile interviului.
Finalitatea precisă, predeterminată, înseamnă că cel puŃin o persoană vine la interviu
cu un anumit scop şi vrea să abordeze un anumit subiect.
AlternanŃa rolurilor, are conotaŃia împărtăşirii gândurilor, a simŃămintelor şi
informaŃiilor, printr-o schimbare continuă a rolurilor. Dacă o parte vorbeşte şi cealaltă ascultă,
se poate vorbi de un discurs (speech) şi nu despre un interviu.
a) Feluri de interviuri
Interviurile sunt utilizate variat, în domenii diverse şi cu interese diferite, ceea ce
conduce la o structură tipologică a acestora, astfel:
• oferire informaŃiilor
• colectarea informaŃiei
• selecŃia
• probleme referitoare la comportament
• rezolvarea de probleme
• vânzări sau prestări de servicii
b) Folosirea interviului
Acesta se foloseşte pentru următoarele situaŃii:
• dacă este nevoie să motivăm o persoană să răspundă liber, deschis şi sincer
• dacă dorim să cunoaştem detalii despre unele răspunsuri sau să clarificăm o
anumită chestiune
• dacă intenŃionăm să adaptăm întrebările şi răspunsurile la fiecare intervievat
sau anchetator
94
• dacă dorim să justificăm sau să explicăm întrebările şi răspunsurile

• dacă vrem să obŃinem răspunsuri mai amănunŃite la unele întrebări
• dacă intenŃionăm să avem controlul asupra întrebărilor, răspunsurilor
participanŃilor la interviu, precum şi asupra unei situaŃii
• dacă dorim să adaptăm interviul la condiŃiile specifice
• dacă considerăm că este necesară cunoaşterea aparenŃei, manierelor, a modului
de a se îmbrăca sau comunica non verbal unele persoane
• dacă suntem preocupaŃi de aflarea detaliilor despre unele trăiri interne, etc., ce
nu se observă în scris
• dacă trebuie să verificăm ca intervievatul este cel ce se pretinde a fi
Întotdeauna interviul urmează chestionarului, cererilor de angajare sau răspunsurilor
scrise. Rezultatele depinzând de instruirea celui ce-l iniŃiază, dar şi de credibilitatea părŃilor.
c) Metode de intervievare
În literatura de specialitate sunt cunoscute două metode şi anume: interviul dirijat şi
cel nedirijat.
Interviul dirijat, aici cel ce ia interviul stabileşte obiectivul interviului şi cel puŃin la
început controlează modul său de derulare. Pot fi situaŃii de preluare a controlului de către cel
intervievat, dar startul aparŃine celui ce ia interviul.
Interviul nedirijat, ce presupune oferirea unor libertăŃi intervievatului de către cel ce ia
interviul. Aici sunt reprezentative interviurile pentru consiliere, evaluarea performanŃelor şi
rezolvarea problemelor.
d) Procesul intervievării
Acesta are elemente relevante şi oameni. În timpul intervievării se obŃin rezultate bune
dacă părŃile dialoghează în cunoştinŃă de cauză a unor elemente comune ce-i leagă.
RelaŃia dintre cele două părŃi este caracterizează prin trei dimensiuni, implicare,
control, afecŃiune.
Implicarea, exprimă gradul în care cele două părŃi doresc să se implice în interviu.
Controlul, ce se referă la puterea fiecărei dintre părŃi, cel ce ia interviul şi
intervievatul, de a influenŃa rezultatul final al acestuia.
AfecŃiunea exprimă gradul de cardinalitate sau prietenia dintre cele două părŃi.
e) InteracŃiunea comunicării
Aici avem trei nivele de interacŃiune şi anume:
Nivelul-1, se referă la interogări protocolare, lejere, fără să nască nici cele mai mici
ameninŃări asupra părŃilor;
Nivelul-2 surprinde aspecte mai intime, cu suficient loc pentru controverse, cum ar fi
comportamente, mentalităŃi, atitudini, credinŃe, sentimente.
Nivelul-3 scoate în evidenŃă cele mai intime şi controversate aspecte, prin modul de
formulare a întrebărilor, însă şi prin răspunsurile ce vor dezvălui total sentimentele, credinŃe,
atitudini, percepŃii.
InteracŃiunile comunicării pot fi verbale sau non verbale, intenŃionate sau
neintenŃionate, iar separarea acestora este dificil de realizat, aproape imposibil.
f) Fedd-back-ul
La interviu, acesta este continuu, atât pentru anchetator cât şi pentru intervievat. Avem
trei variante ale acestuia şi anume:
• confirmarea mesajului primit
• îndreptarea mesajului
• refuzarea mesajului şi reluarea procesului de interogare ca să realizăm un feed-
back performant, este foarte important să ştim să ascultăm
În acest scop avem trei modalităŃi de ascultare:
• ascultarea pentru înŃelegere
95
• ascultarea cu simpatie
• ascultare pentru evaluare
g) Structurarea interviului
El este structurat în trei părŃi majore şi anume: deschiderea, partea principală şi
închiderea
Deschiderea interviului, aici avem două activităŃi distincte;
• stabilirea raportului dintre părŃi, ce constă în crearea sistemului de încredere
dintre participanŃi
• orientarea interviului, ce se referă la explicarea scopului, timpului necesar,
natura interviului, etc…
Partea principală a interviului, ce prezintă structura pe teme şi subteme care urmează
a fi acoperite. SecvenŃele structurii pot fi definite după criteriile alese de realizator astfel:
• secvenŃa tematică, urmează o împărŃire naturală a temei abordate
• secvenŃa temporală tratează tema sau părŃile ei în ordine strict cronologică
• secvenŃa spaŃială ordonează tematica în funcŃie de dispunerea în spaŃiu
• secvenŃa cauză-efect se realizează la prezentarea cauzelor şi efectelor unor
evenimente, probleme, defecŃiuni, etc…
• secvenŃa problemă-soluŃie constă în descrierea fazelor problemei şi a fazelor
soluŃiei rezolvate
SchiŃa domeniilor şi întrebărilor de formulat constituie programul interviului.
Interviurile se pot grupa astfel:
• moderat programat
• puternic programat
• puternic programat standardizat
Închiderea interviului, trebuie să fie scurtă, dar să fie importantă, deoarece şansele
următoarelor interviuri depind de modul cum sau încheiat precedentele.
h) Modul de folosire a întrebărilor
Întrebarea trebuie definită ca orice enunŃ care invită la formularea unui răspuns, deci
întrebările pot să fie:
• deschise sau închise
• principale sau secundare
• neutre sau dirijate
Formularea întrebărilor, poate convinge intervievatul să răspundă liber şi acesta
trebuie să Ńină seama de următorii factori;
• limbaj
• relevantă
• nivel de informare
• complexitate
• accesibilitate
SecvenŃele de formulare a întrebărilor sunt de următorul fel:
• secvenŃe pâlnie, ce încep cu întrebări vagi şi continuă cu cele mult mai
restrictive
• secvenŃe pâlnie întoarsă, ce vor începe invers decât cele precedente
• secvenŃa reprezentării în cinci paşi, se foloseşte la a determina intensitatea
opiniilor şi atitudinilor. Ea are următorii paşi:
o testarea cunoştinŃelor problemei de intervievat
o aflarea atitudinii lui fără a fi influenŃat
o formularea precisă a atitudinii
o motive pentru atitudinea avută
96
o intensitatea atitudinii
i) Planificarea interviului
Un interviu trebuie să fie realizat în concordanŃă cu orientări cadru, cum ar fi:
• planificarea interviului, care se face prin:
o pregătirea intervievaŃilor
o pregătirea unei liste de control
• ascultarea cu atenŃie şi consemnarea lucrurilor interesante
• revizuirea consemnărilor făcute în cel mult 48 de ore de la interviu
• menŃinerea stării neutralitate
• căutarea mai multor puncte de vedere
3.7.2.2. Chestionarul
Acesta este mai puŃin costisitor şi mai redus în timp, el poate oferi un volum mare de
informaŃii necesare analizei sistemului.
a) Proiectarea chestionarului
Conceperea chestionarului este o artă nu numai o ştiinŃă, de aceea sunt unele reguli
recomandabile şi care se pot utiliza drept elemente de comparaŃie pentru a-şi evalua paşii
întregii proceduri. Sunt recomandabili următorii paşi:
• Ce informaŃii vor fi căutate
• Stabilirea tipului de chestionar şi a metodei de administrare
• Determinarea conŃinutului întrebărilor
• Stabilirea modului de redare a răspunsului pentru fiecare întrebare
• Formularea întrebărilor
• Stabilirea secvenŃei întrebărilor
• Validarea caracteristicilor tehnice ale chestionarului
• Reevaluarea paşilor 1-7 şi revizuirea lor
• Efectuarea pre-testului şi revizuirea finală
b) Întocmirea chestionarului
Chestionarele sunt date pe hârtie, ele putându-se face cu sau fără operator uman,
direct, prin telefon sau chiar pe dischetă sau prin intermediul serviciilor oferite de calculator.
Acestea se bazează pe întrebări cu schemă fixă de răspuns, iar atunci când conŃin întrebări cu
formulare vagă au ca scop aflarea părerilor celor chestionaŃi, pentru a putea fi surprinse cât
mai multe cazuri.
În literatura de specialitate se arată că se pot folosi întrebări închise, deschise şi cu
trepte de atitudini.
Cele deschise, unde persoana intervievată nu are nici o restricŃie în ce priveşte
posibilităŃile de a răspunde.
Cele deschise, unde răspunsurile sunt prestabilite şi persoana trebuie să aleagă din cele
propuse, unul sau mai multe.
Cele cu trepte, unde avem un ansamblu de trepte ce permit să se analizeze conŃinutul
şi intensitatea atitudinii celui intervievat faŃă de un concept, un produs, un serviciu, etc. Aici
atitudinile se împart în trei feluri, anume: evaluate, forŃă şi acŃiune.
c) Eşantionarea
Deoarece colectivităŃile studiate depăşesc numărul celor ce sunt chestionaŃi, necesită
stabilirea eşantionului chestionat. În acest scop se folosesc următoarele patru metode [21]:
• cei adecvaŃi eşantionului – sunt oameni care-şi desfăşoară activitatea într-un
loc
97
• grup aleator în cazul că este o listă a tuturor utilizatorilor unui sistem simplu,
se selectează fiecare a n-a persoană , în care n este raŃia de selecŃie
• eşantionul precizat, adică numai persoanele ce îndeplinesc anumite criterii şi
cu o vechime adecvată
• eşantion stratificat, atunci când sunt mai multe categorii de persoane, din care
se aleg după criterii aleatoare, se vor alege doar cei eşantionaŃi
3.7.2.3. Intervievarea grupurilor

Inconvenietul aplicării interviurilor şi chestionarelor pentru colectarea cerinŃelor
sistemelor, este apariŃia unor contradicŃii aparente între datele colectate şi reconcilierea lor,
lucru ce impune intervenŃia analiştilor. Aceasta determină intervievarea grupurilor, unde are
loc intervievarea concomitentă a unui grup de persoane-cheie. Acest lucru este făcut de unul
sau mai mulŃi analişti, realizându-se împărŃirea sarcinilor, unul va avea rolul de operator al
interviului, altul consemnează răspunsurile, iar altul va urmări doar problemele bine definite.
Avantajele interviului în grup sunt [7]:
• folosirea mai eficientă a timpului alocat interviului
• permite intervievaŃilor să-şi asculte reciproc declaraŃiile, ca să le susŃină sau să
le combată, sau să formuleze noi păreri
• permite delimitări clare între punctele de vedere acceptate de toŃi şi cele ce
stârnesc divergenŃe
Dezavantajul principal este în planificarea calendaristică a desfăşurării sale, datorită
participării mai multor persoane ce trebuie să fie concomitent prezente la acest proces.
Grupurile au caracteristici ca [7]:
• un mod simplu de gândire, ceva mai lent decât cel individual
• sensibilitatea sa este instabilă, fără critici colective
• atenŃia sa este mobilă
• o slabă rezistenŃă la oboseală
• este mai xenofob decât fiecare individ în parte
O concluzie generală este că lucru în echipă este mult mai dificil.
3.7.2.4. Observarea directă a utilizatorului

Acesta anulează subectivismul şi se poate realiza prin urmărirea a ceea ce execută
personalul sau prin evaluări obiective ale efectului activităŃii sale. Desfăşurarea ei depinde de
acceptul sau bunele intenŃii ale beneficiarului, avem cazuri când chiar dacă este acceptat,
prezenŃa analiştilor printre angajaŃi în determină pe aceştia să se manifeste anormal, cu scopul
de a crea o impresie anume. Deci, pot fi emoŃionaŃi, stresaŃi, se forŃează să termine lucrările
mai repede, să simuleze ocuparea completă a timpului, sau alte ori pot lucra mai încet bruind
sistemul. Aici apare problema imposibilităŃii observării pe termen lung a sistemului sau chiar
excitarea în mod continuu a acestora, ce presupune alegerea de către analişti a unei palete
largi de probleme.
3.7.2.5. Analiza modului de lucru şi a documentelor

Documentele studiate sunt de o mare diversitate, deci în urma analizei documentelor
putem obŃine informaŃii despre [21]:
• problemele existente în sistemul curent, cum sunt informaŃiile redundante sau
puncte de ştrangulare
• posibilitatea obŃinerii condiŃionată a unor informaŃii
98
• preocupări pe linia schimbării politicii privind tratarea unor categorii de

informaŃii
• numele şi funcŃiile persoanelor direct interesate de soarta sistemului existent
• obiectivele cheie ale beneficiarului şi/sau ale persoanelor sau grupurilor de
persoane pe termen scurt şi lung
• proceduri speciale de prelucrare a unor informaŃii
• motivele proiectării sistemului curent
• datele, regulile de prelucrare a lor, principiile pe care funcŃionează sistemul
informaŃional
În urma acestei analize pot să apară următoarele elemente:
• repetarea activităŃilor la două sau mai multe locuri de muncă declarate cu
sarcini diferite
• absenŃa procedurilor de lucru pentru unele activităŃi
• depăşirea valabilităŃii în timp a procedurii
• procedurile formale contrazise de realitatea constantă prin interviuri,
chestionare şi alte metode folosite
Alt tip de documente studiate de analişti îl constituie formularele folosite de beneficiar
pentru toate tranzacŃiile interne şi externe ce au loc. Un alt tip de documente îl constituie
rapoartele generate de actualul sistem. Ultimul tip de documente sunt doar în sistemele de
prelucrare automată a datelor şi se referă la documentaŃia folosită în sistemul informatic. În
alegerea procedeelor de analiză a sistemului existent, se au în vedere obiectivele echipei de
analiză şi asigurarea scopului propus de acestea.
3.7.3. Studierea componentelor sistemului existent

Aceasta presupune o cunoaştere detailată a structurii organizatorice a unităŃii
beneficiare, a activităŃilor, a proceselor economice şi mijloacelor de calcul folosite, a fluxului
informaŃional rezultat din circulaŃia documentelor între compartimente, determinarea
volumului datelor din sistemul informaŃional, inclusiv identificarea cheltuielilor de
funcŃionare a sistemului existent.
1. Studierea structurii organizatorice. Aceasta vizează obiective ca:
• cunoaşterea scopului activităŃilor de bază
• descrierea fluxurilor de producŃie şi a tipului de fabricaŃie
• urmărirea dinamicii unor indicatori tehnico-economici
• determinarea modului de ierarhizare a sectoarelor de producŃie şi a
compartimentelor funcŃionale, cu ajutorul organigramei structurii
organizatorice a unităŃii studiate
• referirea la metoda de raportare şi planificare utilizată, forma de contabilitate,
metoda de evidenŃă a valorii materialelor şi cea de calculare a costurilor
• determinarea relaŃiilor informaŃionale dintre unitatea studiată şi organele
ierarhice superioare şi inferioare
ParticularităŃile structurii organizatorice vor fi utilizate de echipa de analiză ca element
de referinŃă în studiul celorlalte probleme specifice întregului sistem existent, la
fundamentarea de soluŃii în proiectarea şi realizarea viitorului sistem informatic.
2. Studierea activităŃilor şi a dotării cu tehnică de calcul. Ea vizează natura şi
specificul activităŃilor desfăşurate, documentele utilizate în cadrul fiecărei activităŃi şi
compartimente funcŃionale implicate în funcŃionarea sistemului informaŃional existent.
Studierea este concretizată în activităŃi ca [21] [27]:
• planificare
99
• cercetare ştiinŃifică şi dezvoltare tehnologică

• introducerea progresului tehnic
• investiŃii
• programarea, lansarea şi urmărirea producŃiei
• întreŃinerea şi repararea fondurilor fixe
• controlul tehnic de calitate
• gospodărirea fondurilor fixe, a resurselor materiale şi organizarea tehnico-
materială
• comerŃ interior şi exterior
• transport intern
• financiar-contabil
• personal
Aceste activităŃi sunt studiate prin prisma documentelor utilizate de fiecare
compartiment în parte. Evenimentele neconcordante dintre numărul şi conŃinutul
documentelor utilizate şi prevederile legale, trebuie semnalate de echipa de analiză care va
solicita utilizarea doar a documentelor prevăzute în normele legale şi va determina
conducerea unităŃii să ia măsuri de eliminare imediată a documentelor utilizate, dar
neprevăzute în cadrul legislativ. Odată cu studierea activităŃilor se va analiza şi dotarea cu
tehnică de calcul a unităŃii şi gradul de utilizare a ei, precum şi faptul de a putea fi utilizată în
noul sistem informaŃional preconizat de echipa de proiectare.
3. Studierea fluxurilor informaŃionale. Cu ajutorul lui, se identifică circuitul
documentelor în cadrul compartimentelor şi între acestea, în scopul realizării practice a
obiectivelor activităŃilor care fac obiectul prelucrării actualului sistem. Această studiere are ca
scop realizarea unor deziderate ca [21]:
• descrierea fluxurilor informaŃionale cu ajutorul unei organigrame ce va preciza
activităŃile desfăşurate, compartimentele implicate, operaŃiile şi circuitele
documentelor în cadrul fiecărui compartiment şi între compartimente, cu
ajutorul simbolurilor specifice
• prezentarea fluxurilor informaŃionale paralele, inutile şi neraŃionale ce trebuie
eliminate din sistemul informaŃional
• stabilirea documentelor ce circulă în mod inutil şi sunt în contradicŃie cu cadrul
legal normativ sau sunt completate într-un număr de exemplare
necorespunzătoare cerinŃelor reale ale sistemului
• calcularea gradului de utilizare a documentelor tipizate cu scopul identificării
documentelor netipizate şi a eliminării totale a lor din fluxurile informaŃionale
• stabilirea oportunităŃii datelor din documentele utilizate pentru precizarea
datelor neutilizabile, nevalorificate în totalitate sau neincluse în conŃinutul
documentelor
• calcularea gradului de încărcare şi solicitare a fiecărui compartiment implicit în
cadrul funcŃionării sistemului actual
• integrarea sistemului informaŃional specific unităŃii cu alte sisteme
informaŃionale existente
Simbolurile (BISAD) de prezentare a fluxului informaŃional sunt următoarele:

Ce? C
â
n - prelucrare
d
Cine? ?
100
- fişier de orice tip
- document într-un singur exemplar
1
2
3 - document în 3 exemplare
- simbol de document arhivat
- direcŃia de circulaŃie a documentelor şi

informaŃilor
- contor de continuare flux pe altă pagină
- contor de circulaŃie flux pe aceeaşi pagină
Simboluri ASME, pentru diagrame de flux FLOW-CHART
- crearea unui document nou, concomitent cu efectuarea unei operaŃii în el
- adăugarea de date pe un document
- operaŃii asupra unui document, prin care nu se adaugă informaŃii
- verificarea, compararea, corectarea, revizuirea unui document
- mişcarea sau transportul unui document de la un compartiment la altul
- staŃionarea sau îndosarierea temporară a unui document
101
- arhivarea unui document
- distrugerea unui document
- verificarea unui document împreună cu o operaŃie de îndosariere, capsare,

etc.
- verificarea unui document împreună cu operaŃia de semnare sau modificare a

sa
2 - crearea unui document în trei exemplare
Linii de influentă:
1
- documentul de la nivelul unu influenŃează apariŃia altui document la
nivelul doi
1 1
- documentul ce circulă la nivelul unu influenŃează a scrie pe
documentul de la nivelul doi, apoi o capsare sau
îndosariere a sa
2 2
1
- documentul ce circulă la nivelul unu influenŃează o verificare cu
semnare a documentului de la nivelul doi
1
2 - înregistrarea concomitentă trei exemplare
3
102
- linii de neinfluenŃă (una din două)
1
2 - transportul celor trei exemplare
3
Principii de utilizare a diagramelor ASME:

1. Nu pot să apară mai multe documente la acelaşi nivel.
2. Un document de la apariŃie până la dispariŃie îşi păstrează nivelul.
3. Un document intră în circuit astfel:
• din afara compartimentului
• scos din dosar sau arhivă, deschidere de fişier
• ca nou document într-un exemplar sau mai multe
4. Un document îşi termină circuitul astfel:
• când iese afară din unitate
• staŃionează la acel compartiment
• arhivare la acel compartiment, închidere de fişier
• distrugerea sa
5. Un compartiment poate apare într-o diagramă de flux de câte ori este necesar
6. Nu se admit întoarceri ale documentului într-un flux, deoarece îşi schimbă nivelul de
circulaŃie.
4. Studiul volumului datelor din sistemul informaŃional.

Aceasta urmăreşte consemnarea numărului de documente utilizate în actualul sistem
informaŃional şi estimarea evoluŃiei numărului mediu de documente, pentru a reflecta cât mai
veridic în noul sistem cantitatea relativă de date ce va fi prelucrată prin intermediul
calculatorului. Acest studiu urmăreşte şi cuantifică elemente ca:
• simbolul şi denumirea documentelor utilizate
• frecvenŃa de utilizare a documentelor, pentru exprimarea volumului de date
• numărul maxim şi mediu de documente corespunzător frecvenŃei unitare de
utilizare
• numărul mediu de rânduri completate şi numărul total de rânduri pe document
• numărul de exemplare în care se completează documentul
• stabilirea numărului mediu de documente pentru o perioadă viitoare de minim
5 ani
Pe baza calculelor făcute prin studiul volumului datelor din sistemul
informaŃional, echipa de analiză poate stabili recomandări privind configuraŃia calculatorului.
Elementele prezentate vor constitui surse ale evaluării critice pentru actualul sistem.
5. Studiul costurilor de funcŃionare ale actualului sistem.

Acestea permit determinarea categoriilor de cheltuieli efectuate de unitatea
beneficiară, pentru stabilirea efortului financiar al unităŃii de întreŃinere a sistemului existent.
Avem următoarele cheltuieli cu actualul sistem:
• cheltuieli cu salariile personalului implicat în funcŃionarea actualului sistem
• cheltuieli cu amortizarea şi întreŃinerea echipamentului de calcul
• cheltuieli cu amortizarea clădirilor în care are loc procesul informaŃional
103
• cheltuieli cu materialele
• alte cheltuieli necesare funcŃionării actualului sistem
Acest studiu va fi folosit în evaluarea critică a sistemului existent precum şi la
calcularea indicatorilor de eficienŃă stabilită în etapa de implementare prin care se compară
cheltuielile de funcŃionare ale vechiului sistem în raport cu cele ale sistemului informatic
proiectat.
3.7.4. Metode de stabilirea cerinŃelor sistemului existent

Au apărut mai multe metode, cum ar fi: JAD (Joint Application Design), sistemele de
sprijinire a grupurilor, instrumentele CASE, prototipizarea şi stabilirea cerinŃelor sistemului,
RAD (Rapid Application Development) şi XP (Extreme Programming).
3.7.4.1. Metoda JAD

Ideea principală JAD o constituie punerea împreună a tuturor forŃelor interesate în
dezvoltarea sistemelor utilizator-cheie, managerii şi analiştii de sistem implicaŃi în analiza
sistemului. În JAD se urmăreşte o anumită secvenŃa de derulare a activităŃilor, având la bază
roluri bine definite.
Sesiunile JAD se desfăşoară în locuri diferite de cele unde lucrează persoanele
antrenate aici. Scopul ar fi de a-i Ńine departe de grijile locului de muncă şi de a-i folosi intens
în şedinŃele de lucru. Acestea pot dura de la 4(patru) ore la o săptămână, sunt cazuri că ele se
pot repeta de mai multe ori, iar costul este de sute milioane de lei
La sesiunile JAD participă următorii:
• conducătorul sesiunii JAD
• beneficiarii
• managerii
• susŃinătorul/sponsorul, dacă este cazul
• secretarul ce notează tot pe calculator (scribul)
• informaticieni
Sesiunile se Ńin de regulă în săli speciale sub formă de potcoavă. La închiderea sesiunii
se obŃine ca rezultat un set de documente referitoare la activităŃile din sistemul actual şi care
au legătură cu noul sistem.
Analişti obŃinând o imagine asupra a ceea ce intenŃionează să realizeze şi ce are
beneficiarul.
3.7.4.2. Sistemul de sprijinire a grupurilor

Dezavantajul sesiunii JAD, îl constituie numărul mare de participanŃi şi deci
diversitatea părerilor afişate într-un timp limitat, deci timpul persoanei este limitat în a lua
cuvântul la câteva minute.
SoluŃia este sistemele de sprijinire a grupurilor, care vor rezolva problemele întâlnite
de grup. Aici fiecare membru al grupului are şansa de a-şi exprima părerea fără a fi nevoit să
o spună verbal, introducând în calculator tot ce crede despre acea problemă. Deci în timpul
alocat fiecărui membru, el poate beneficia din plin de şansa de a scrie orice pe calculator, cu
cât autorii afirmaŃiilor îşi păstrează anonimatul. În acest fel sesiunile JAD vor câştiga în
eficienŃă.
Aici avem posibilitatea de achiziŃie a cunoştinŃelor de la grupuri de experŃi, iar
rezultatele vor fi excelente.
104
3.7.4.3. Prototipizarea şi stabilirea cerinŃelor sistemului

Acesta este un proces iterativ prin care analiştii şi utilizatorii pun în discuŃie o versiune
rudimentară de sistem informaŃional, ce este într-o continuă schimbare în funcŃie de reacŃia
utilizatorilor. Acestea conduc la renunŃarea la ciclul de viaŃă al dezvoltării sistemelor sau la
creşterea rolului său.
Prototipizarea este operaŃia de culegere a informaŃiilor, cea mai simplă şi solicită un
timp mai scurt decât interviul. Acesta este prezentat la testare utilizatorului, fiind posibil de a
se preciza ceea ce se doreşte, putându-şi genera o formă nouă cu ajutorul propriilor specialişti.
Ea este facilitată de limbaje sau produse program din generaŃia IV, incluşi CASE.
Aceasta este folositoare în determinarea cerinŃelor sistemului atunci când:
• cerinŃele beneficiarului nu sunt clar formulate sau bine înŃelese
• unul sau mai muŃi utilizatori sau susŃinători sunt implicaŃi în sistem
• dacă au fost dificultăŃi în comunicarea dintre utilizatori şi analişti, pentru
formarea cât mai corectă a cerinŃelor sistemului
• anumite mijloace de lucru (rapoarte, etc.) şi datele de test existente sunt
elemente ce contribuie la construirea mai rapidă a sistemului.
Prototipizarea are următoarele etape de realizare [21]:
• identificarea cerinŃelor principale ale beneficiarului
• realizarea rapidă a unui prototip
• predarea beneficiarului pentru testare
• obŃinerea reacŃiilor beneficiarului
• modificarea prototipului dacă este cazul, care se subdivide:
o prototip abandonat
o dezvoltarea în continuare a prototipului
o predarea beneficiarului din nou pentru testare
Avantajele prototipizării sunt [27]:
• definirea mai bună a cerinŃelor beneficiarului
• implicarea puternică a beneficiarilor şi creşterea satisfacŃiei lor
• creşterea vitezei de realizare a sistemelor
• reducerea numărului de erori
• flexibilitatea mare la potenŃiale schimbări
• costuri mici de realizare a sistemului, aproximativ 10-20 % din cele
tradiŃionale
Prototipizarea are următoarele deficienŃe:
• tendinŃa de evitare a unui cadru formal de elaborare a documentaŃiei privind
cerinŃele sistemului, care îngreunează controlul
• deoarece este conceput în colaborare cu un grup nesemnificativ de utilizatori,
poate fi respins de viitorii utilizatori
• fiind conceput izolat, este mai greu de integrat în sistemul existent
• nerespectând etapele ciclului de viată, el poate omite aspecte esenŃiale, cum ar
fi: securitatea, controlul datelor şi standardizare la nivel de sistem
Prototipizarea se poate folosi în următoarele condiŃii:
• beneficiarii nu ştiu prea bine ce vor sau cerinŃele lor sunt într-o continuă
schimbare
• cerinŃele sistemului sunt greu de definit
• nu se cunosc intrările şi ieşirile sistemului
• activităŃile de executat sunt semi-structurate sau nestructurate
105
• sistemul de realizat este necesar într-o perioadă foarte scurtă de timp şi este
cerinŃă majoră pentru beneficiari
• riscul oferirii unui sistem inadecvat este foarte mare
• reacŃiile beneficiarului faŃă de noul sistem contribuie esenŃial la realizarea sa
• cerinŃa de testare a mai multor strategii de proiectare
• personalul implicat în realizarea sistemului stăpâneşte mijloacele oferite de
generaŃia IV de limbaje şi de prototipizare
• personalul de proiectare nu dispune de experienŃa necesară dezvoltării unui
sistem sau a unei aplicaŃii
• sistemul va avea o utilizare temporară
Sistemele care se pretează la prototipizare sunt:
• cele de sprijinire a procesului decizional
• cele informaŃionale pentru top manageri
• cele expert
• cele de reconstituire a informaŃiilor
Aceasta nu este recomandabilă pentru sisteme mari şi pentru cele complexe, ce au o
arie mare de extindere.
Prototipizarea serveşte ciclului de viaŃă al dezvoltării sistemelor şi nu contribuie la
renunŃarea la o astfel de metodologie, ea va conduce la înlocuirea în totalitate a
metodologiilor şi instrumentelor tradiŃionale de realizare a sistemelor.
3.7.4.4. Metoda RAD

Metoda câştigă teren datorită simplităŃii cu care sunt abordate sistemele, iar din ciclul
de viaŃă al sistemelor se folosesc doar patru etape.
Ea este o metodologie de realizare a sistemelor informatice ce permite sisteme mai
bune, mai ieftine şi realizate mai rapid. Aici sunt aleşi cei mai buni proiectanŃi de sistem şi cei
mai reprezentativi beneficiari, care împreună, în timp real lucrează la realizarea sistemului.
RAD se bazează pe doi factori substanŃiali, cum ar fi [4]:
• sporirea vitezei de derulare a operaŃiilor economice şi odată cu aceasta,
diminuarea posibilităŃilor de control asupra lor
• apariŃia multor instrumente puternice bazate pe folosirea calculatorului în
domeniul realizării sistemelor, ca: CASE şi prototipizarea
DiferenŃa dintre RAD şi JAD constă în faptul că prototipul devine elementul
fundamental al noului sistem, ecranele afişate în timpul prototipizării devin ecrane ale
sistemului şi nu modele ale unui posibil sistem.
Suportul central este oferit de instrumentele integrate în CASE, în care sunt incluse şi
generatoarele de coduri ale programării.
Reuşita sa depinde de următoarele elemente [7]:
• instrumentele folosite
• personalul existent
• managementul existent
• metodologia utilizată
Etapele ciclului de viaŃă sunt: planificarea, analiza, proiectarea şi implementarea, iar
pentru RAD avem: planificarea cerinŃelor, proiectul utilizatorului, construirea şi fasonarea sa.
Planificarea cerinŃelor RAD, reprezintă tradiŃionalele activităŃi de identificare şi
alegere a proiectelor precum şi activităŃii de tip analiză.
106
Proiectul utilizatorului, unde beneficiarul final şi informaticienii vor participa la

ateliere de lucru JAD, unde cei implicaŃi apelează la mijloace de lucru CASE pentru obŃinerea
rapidă a prototipului proiectului sistemului.
La construcŃie, specialiştii în informatică, autorii proiectului vor genera codurile
produsului, folosind instrumentele CASE de acest gen, precum şi manualele de codificare, în
cazul că este necesar. Aici se face asamblarea unor componente realizate anterior, prin
interfeŃe interne care să efectueze legăturile dintre ele. La sistemele mici etapa de construcŃie
poate fi cumulată cu proiectul utilizatorului.
Fasonarea (implementarea), înseamnă distribuirea produsului spre beneficiarul final.
Deoarece RAD este rapid, planificarea fasonării trebuie începută mai devreme.
În figura următoare se poate vedea modul de derulare în RAD:
IniŃializare
Formularea
cerinŃelor
Proiectare
Realizare
Implementare
Figura 3.8 Modul de derulare RAD [7]

RAD-ul poate avea avantaje dintre care amintim unele în continuare.
Ca un prim avantaj ar fi că, sistemele informaŃionale pot fi realizate într-un timp de
patru ori mai scurt decât metodele tradiŃionale, deci sunt mult mai ieftine.
Implicarea personală a beneficiarului duce ca riscul nereuşitei să se diminueze, iar
calitatea sistemului sporeşte datorită numeroaselor teste ce se fac pe parcurs.
Reducerea timpului de definitivare a proiectului şi punerea lui în lucru, duce la
răspunderea mai rapidă şi mai bună la cerinŃele beneficiarului.
ConsistenŃa, care apare datorită rapidităŃii analiştilor RAD, ce neglijează existenŃa
unor ecrane interne ale aplicaŃiei, dar şi cele din alte aplicaŃii.
Standardele de programe, ce sunt realizate în fazele timpurii ale RAD şi face dificilă
implementarea mai târziu.
Refolosirea modulelor, în unele cazuri analiştii omit sau nu au timp să cerceteze dacă
aceleaşi ecran sau rapoarte mai există în alte aplicaŃii.
Scalabilitatea, arată că sistemul proiectat de RAD este util, folosirea sa conduce la
extinderea ariei beneficiarilor iniŃiali ce au participat la construirea sistemului. Deci
realizatorii trebuie să aibă în obiectiv o astfel de extensie, care se referă la: echipamente, aria
de întindere a sistemului, numărul, tipurile şi utilizatorii rapoartelor, creşterea echipei de
dezvoltare şi întreŃinere a sistemului, instruirea beneficiarilor, securitatea datelor.
Administrarea sistemului este aproape neglijată în timpul RAD. Apar probleme ca:
întreŃinerea şi reorganizarea bazelor de date, constituirea copiilor de siguranŃă şi reconstruirea
sistemului după avarii, etc., toate fiind relevante pentru asigurarea protecŃiei şi securităŃii
sistemului.
107
Succesul RAD înseamnă succesul tuturor tehnicilor moderne folosite în analiza şi

proiectarea sistemelor.
Metoda RAD implică dezvoltarea unei soluŃii într-un interval de 60-90 de zile. În
cazul în care se optează pentru folosirea unei asemenea metode, trebuie să luăm în calcul
faptul că, în cazul sistemelor extreme de complexe dezvoltarea nu poate fi încheiată decât cu
anumite compromisuri. Figura ne redă evoluŃia unui proiect care utilizează metoda RAD.
Figura 3.9 Aplicarea metodei RAD [1]

Metoda are în vedere următoarele premize:
• în multe cazuri o aplicaŃie funcŃională în proporŃie de 80% poate fi dezvoltată
în doar 20% din timpul total alocat respectivei dezvoltări
• în multe situaŃii acceptabilitatea unui sistem poate fi făcută doar pe baza unui
set minim de cerinŃe pe care respectivul sistem le îndeplineşte urmând ca restul
funcŃionalităŃilor să fie dezvoltate ulterior momentului acceptării
3.7.4.5. Metoda XP
Extreme Programing (XP) a evoluat datorită problemelor cauzate de ciclurile lungi de
dezvoltare ale modelelor tradiŃionale. Metoda a pornit iniŃial, ca o modalitate de a obŃine
rezultate într-un timp foarte scurt, aplicând practici care şi-au dovedit succesul de-a lungul
timpului. După un număr de încercări reuşite în practică, metoda XP a fost „teoretizată” pe
baza unor principii şi practici considerate de bază. Trebuie menŃionat faptul că, practicile
prezente în XP nu sunt noi, ci au fost preluate din cele existente, care şi-au dovedit
eficacitatea de-a lungul timpului în diverse procese de dezvoltare. Termenul „extrem”
sugerează de fapt, ducerea acestor principii şi practici la extrem.
Metoda XP promovează 4 valori ridicate la rangul de principii [Sommerville, 2004]:
• comunicarea – reprezintă un criteriu esenŃial de succes al unui proiect. De
multe ori, problemele care apar la dezvoltarea unui sistem informatic, sunt
datorate lipsei de comunicare între membrii echipei.
• simplitatea – este de dorit dar, atingerea ei nu este accesibilă începătorilor. Ca
să fie simplu, trebuie să ai o anumită experienŃă a unor proiecte anterioare.
Ceva ce este simplu este foarte puŃin probabil să genereze erori, iar dacă le
generează acestea pot fi controlate şi rectificate în timpul util. O soluŃie simplă
nu trebuie confundată cu o soluŃie simplistă. SoluŃia simplă înseamnă maximul
de compromis dintre complexitate şi flexibilitate. O soluŃie devine simplă prin
rafinare. Dacă de la bun început apare o asemenea abordare este foarte probabil
108
ca persoana care o propune să fi avut anterior o experienŃă îndelungată în

tratarea respectivei probleme.
• feed-back-ul – reprezintă „combustibilul” echipei. Îi motivează profesional să
meargă mai departe şi să rezolve sau să ajusteze soluŃia astfel încât să aibă un
retur cât mai bun din partea clientului. Feed-back-ul poate fi perceput din
perspectiva temporală, perspectiva clientului, perspectiva programatorului. Din
perspectiva temporală putem avea feed-back la nivel de minute, ore, zile în
etapa de dezvoltare sau la nivel de săptămâni şi luni în etapa de implementare
şi exploatare. Din perspectiva clientului, feed-back-ul reprezintă instrumentul
prin intermediul căruia se poate modifica modul în care sistemul rezolvă o
anumită problemă. Din perspectiva dezvoltătorului, feed-back-ul este singura
modalitate de a vedea că rezultatele muncii sale nu au fost în zadar, sau de a
duce sistemul către obiectivele urmărite de client. Feed-back-ul evoluează cu
celelalte trei valori: comunicarea, simplitatea şi curajul
• curajul – Ńine de angajamentul pe care Ńi-l iei în faŃa clientului de a-i rezolva
problemele într-o perioadă mai scurtă decât concurenŃii tăi. De multe ori, se
prezintă clientului un sistem care nu are anumite funcŃiuni dar care sunt vitale
activităŃii de zi cu zi a clientului. În această metodologie se poate constata pe
parcursul implementării unui sistem, că o abordare este greşită. Se anulează
munca de câteva zile a echipei şi se alege o nouă cale care să rezolve problema
în termen de buget şi de timp impuse.
Un alt principiu al metodei XP este dezvoltarea unui sistem de calitate. Acest principiu
are la bază ideea că membrii unei echipe doresc dezvoltarea unui soft de calitate, care să le
uşureze ulterior munca implicată de etapa de mentenanŃă. Fără o asemenea premiză este
puŃin probabil să se exercite un control eficient asupra oamenilor care fac parte din echipa de
dezvoltare.
Metoda XP constă în 5 faze după cum urmează [44]:
• exploatarea – în această fază utilizatorii spun ce ar trebui să facă aplicaŃia într-
o lansare iniŃială. Fiecare utilizator aduce la cunoştinŃa dezvoltătorilor
facilităŃile care ar trebui incluse în prima versiune. În acelaşi timp echipa se
acomodează cu instrumentele, tehnologia şi practicile care vor fi utilizate în
proiect. Se testează tehnologia care va fi utilizată şi posibilităŃile arhitecturale
prin construirea unui prototip. Durata fazei este de la câteva săptămâni la
câteva luni, cea ce depinde de faptul, de cât de familiarizaŃi sunt programatorii
cu tehnologia folosită.
• planificarea – stabileşte o prioritate a cerinŃelor utilizatorilor şi se stabilesc ce
funcŃionalităŃi va conŃine primul prototip funcŃional. Se estimează efortul
necesar dezvoltării acestui prim prototip şi se stabileşte un calendar al
dezvoltării lui. Perioada de timp până la lansarea primului prototip nu
depăşeşte două luni. Faza de planificare durează câteva zile.
• iteraŃii până la obŃinerea unui prim prototip funcŃional – include cele
câteva iteraŃii care sunt făcute până la primul prototip funcŃional. În prima
iteraŃie trebuie selectate acele cerinŃe care impun arhitectura întregului sistem.
Apoi clientul va selecta facilităŃile implementate în cadrul fiecărei iteraŃii.
Fiecare iteraŃie este încheiată prin rularea testelor realizate de client. La
sfârşitul ultimei iteraŃii sistemul trebuie să fie în măsură să fie utilizat în
producŃie.
• trecerea în producŃie a prototipului – necesită o testare şi verificare
suplimentară a performanŃelor sistemului înainte ca acesta să fie livrat
clientului. În această fază pot intervenii noi schimbări, rămânând la latitudinea
109
echipei dacă acestea vor fi incluse în prototipul final. În cadrul acestei faze
iteraŃiile pot fi accelerate de la trei săptămâni la o săptămână. Sugestiile şi
ideile care apar în această fază, sunt preluate pentru a fi realizate în etapa de
mentenanŃă. După ce prima versiune este implementată şi lansată în exploatare,
echipa trebuie să fie pregătită pentru noi iteraŃii. Viteza de dezvoltare se poate
accelera după lansarea în exploatare a sistemului.
• mentenanŃă şi încetarea acordării de asistenŃă pentru produsul soft – în
perioada de mentenanŃă ritmul cererilor cu privire la eventualele erori sau
funcŃionări anormale, se diminuează ca frecvenŃă dar nu şi ca potenŃial de
periculozitate. Oricând poate să apară o cerinŃă, care să dovedească faptul că,
undeva în etapa de început lucrurile nu au fost corect abordate necesitând
schimbări serioase ale arhitecturii. În etapa de mentenanŃă ritmul dezvoltării se
reduce până aproape de zero. Încetarea apare atunci când utilizatorul nu mai
are noi cazuri sau noi cerinŃe de implementat şi utilizatorul este mulŃumit de
performanŃa sistemului. Acesta este momentul în care documentaŃia produsului
este scrisă, dat fiind faptul că nu vor mai apărea schimbări majore ale
arhitecturii sau noi facilităŃi. Încetarea poate să apară şi dacă se constată că
sistemul nu şi-a atins obiectivele, sau când dezvoltarea sa în continuare nu
justifică investiŃia.
Metodele XP aduc în discuŃie roluri diferite pe care participanŃii le au într-o dezvoltare
ce adoptă XP [44]:
• programatorii – scriu codul sursă şi testează aplicaŃia. Încearcă să Ńină codul
sursă cât mai simplu şi comunică cu membrii altor echipe.
• client – este persoana sau organizaŃia care va beneficia de utilizarea sistemului.
Stabileşte cerinŃele, dacă aceste cerinŃe sunt îndeplinite precum şi prioritatea
acestora. El furnizează o descriere a funcŃiunilor şi oferă teste de verificare a
funcŃionalităŃii.
• tester – este persoana care verifică faptul dacă testele întocmite de client sunt
conform cerinŃelor. Ei rulează periodic testele asupra sistemului, pentru a
verifica faptul că acestea nu au fost între timp alterate în urma altor intervenŃii.
• monitorul – este persoana care evaluează progresele realizate de echipă, dacă
acestea se va încadra în termenele şi bugetul propus, iar pe baza acestora
furnizează feed-back-ul.
• antrenorul – persoana care este responsabilă de evoluŃia întregului proiect. O
aplicare a principiilor XP face din această persoană factorul coordonator al
întregul proces. El trebuie să fie suficient de experimentat pentru a oferi suport
şi sprijin echipei precum şi soluŃii la problemele mai dificile care apar. Este un
fel de manager de proiect.
• consultantul – persoana externă care oferă informaŃii tehnice pentru realizarea
proiectului. De multe ori consultantul este desemnat din partea clientului şi
este o persoană care cunoaşte foarte bine procesul, astfel încât să poată oferi
lămuriri echipei cu privire la aspecte legate de respectivul domeniu.
• managerul – este persoana care ia decizii. Acesta evaluează starea în care se
află proiectul şi pe baza acestor date ia decizii.
3.7.5. Evaluarea critică a actualului sistem

Ea urmăreşte evidenŃierea performanŃelor şi limitele acesteia în raporturi cu cerinŃele
sistemului de conducere, pentru a stabili principalele direcŃii de ameliorare a calităŃii
sistemului şi de a defini una sau mai multe variante de utilizare globală.
110
Stabilirea unor aprecieri critice asupra sistemului informaŃional are la bază ansamblu
criteriilor de calitate impuse acestuia prin prisma informaŃiilor economice prelucrate şi
difuzate diverşilor utilizatori din unitatea economică.
Aprecierea calităŃii informaŃiei se face prin: precizie, operativitate, frecvenŃă de
difuzare, etc…
Precizia se referă la fidelitatea cu care este reflectată activitatea desfăşurată la unitate
şi este determinată de ansamblul de caracteristici folosite pentru reprezentarea mijloacelor,
fenomenelor şi proceselor tehnico-economice şi sociale.
Operativitatea se referă la executarea procesului de culegere, transmitere, stocare,
prelucrare şi difuzare a informaŃiilor privitoare la procesele şi fenomenele economice din
unitate.
FrecvenŃa de difuzare ce precizează ritmul de transmitere a documentelor şi
informaŃiilor către utilizatori într-un interval de timp unitar (zilnic, decadal, lunar, trimestrial,
etc.).
Evaluarea critică a sistemului informaŃional existent cuprinde: obiectivele sistemului,
mijloacele şi metodele folosite pentru culegerea, transmiterea, stocarea, prelucrarea şi
difuzarea informaŃiilor, personalul şi costurile de funcŃionare.
1. Evaluarea critică a obiectivelor. Aceasta urmăreşte să determine modul cum sunt

rezolvate cerinŃele în prezenŃa realizării perogativelor acesteia prin intermediul unui sistem de
informaŃii ce asigură compararea cerinŃelor impuse de cadrul legal cu modul cum se aplică în
practică de unitatea studiată, metodologiile unitare de planificare, contabilitate, statistică,
analiză, etc.
Tot această evaluare trebuie să arate în ce măsură informaŃiile solicitate lipsesc sau
sunt necorespunzătoare sub aspectul preciziei operativităŃii sau frecvenŃei de difuzare.
Evaluarea critică a obiectivelor evidenŃiază concordanŃa dintre nivelele structurii
organizatorice şi categoriile de informaŃii necesare fiecărui compartiment. Cu această fază de
evaluare, sunt comparate obiectivele concrete asigurate de sistemul existent în unitatea
beneficiară cu obiectivele general valabile pentru toate sistemele din unităŃile economice ce
aparŃin aceluiaşi domeniu de activitate prin raportarea permanentă la cerinŃele şi restricŃiile
cadrului legislativ-normativ. CalităŃile şi deficienŃele sistemului existent pot fi influenŃate de
stilul şi metodele de muncă ale conducerii unităŃii şi ale compartimentelor funcŃionale
implicate. Se pot stabili măsuri prin care unitatea beneficiară să asigure cadrul legislativ şi
organizatoric necesar perfecŃionării sistemului existent.
Evaluarea critică poate urmări în ce măsură suprasolicitarea canalelor informaŃionale
este determinată de aşezarea pe o nouă bază calitativ superioară a proceselor de
autoconducere şi autogestiune. Deci creşterea autonomiei unităŃii beneficiare trebuie însoŃită
şi de lărgirea limitelor şi a delegărilor de atribuŃii pe toate treptele de conducere din unitatea
analizată. Acest element implică activităŃi suplimentare de analiză şi decizie ce pot conduce la
modificarea sensului unor fluxuri informaŃionale. In final, echipa de analiză poate propune
crearea în nomenclatorul de funcŃiuni a unităŃii beneficiare, de nuclee sau posturi de
metodologii specializaŃi în raŃionalizarea, modificarea şi întreŃinerea în exclusivitate a
sistemului propriu.
Propunerilor formulate trebuie însoŃite de modificări în fişele posturilor pentru
funcŃiile implicate în executarea sistemului existent pentru instaurarea unei discipline ferme a
muncii care să asigure trecerea pe o treaptă superioară calitativ a sistemului proiectat.
2. Evaluarea critică a tehnicii de calcul existente.
Prin ea se evidenŃiază gradul de dotare a unităŃii beneficiare în tehnica necesară la
culegerea, transmiterea şi prelucrarea datelor. Echipa de analiză va trebui să discernă asupra
oportunităŃii tehnicii de calcul existente, pentru prelucrarea necesară noului sistem. Se va
111
verifica şi concordanŃa între dimensiunea volumului de informaŃii vehiculate în actualul

sistem şi capacitatea maximă de prelucrare a calculatorului existent. Această evaluare critică
poate indica gradul de fiabilitate a calculatorului şi măsura în care aceasta este compatibil cu
exigenŃele informaŃionale prezentate şi previzibile ale sistemului existent.
Se va verifica şi gradul de integrare informatică a unităŃii beneficiare (dacă există) în
cadrul forului tutelar sau cu alte unităŃi de acelaşi fel.
3. Evaluarea critică a personalului. Ea este folosită în sistemul existent cu scopul de
a determina gradul de utilizare a timpului de lucru pe compartimente şi gradul de încărcare a
fiecărei persoane. Prin ea se pot indica dacă structura pe profesii a personalului şi
specializarea este în concordanŃă cu exigenŃele impuse de funcŃionarea actualului sistem. Se
mai pot face aprecieri asupra gradului de perfecŃionare profesională a personalului din
sistemul existent.
Sintactic evaluările echipei de analiză, vizează următoarele aspecte:
• numărul total de documente şi informaŃii vehiculate de sistem, raportat la total
persoană
• volumul total de ore muncă necesare desfăşurării activităŃilor din sistemul
existent şi calculul ponderii acestuia în fondul de timp maxim disponibil
• numărul mediu de informaŃii prezente în documentele utilizate, corelat cu
gradul de complexitate a acestora
• numărul mediu de ore necesar pentru completarea şi utilizarea unui document;
• numărul mediu de ore necesar pentru vehicularea a 1000 informaŃii
• productivitatea muncii calculată pe o persoană ocupată în funcŃionarea
actualului sistem
• ponderea salariilor aferente personalului ocupat în actualul sistem, în fondul
total de salarii al unităŃii studiate, inclusiv dinamica acestor indicatori
În final echipa de proiectare poate face aprecieri asupra gradului de pregătire a
personalului din unitatea de informatică în viziunea conceperii şi realizării unui sistem
informatic pe bază de contract sau cu efect propriu.
4. Evaluarea critică a costurilor. Ea presupune evidenŃierea măsurilor de reducere a

tuturor cheltuielilor de funcŃionare a sistemului existent, ce trebuie să asigure valorificarea
intensivă a informaŃiilor necesare şi suficiente. Prin această evaluare se pot formulariza unele
propuneri concrete pentru organizarea unei evidenŃe complete şi exacte a tuturor cheltuielilor
aferente sistemului existent. Se pot preciza şi efectele negative care ar putea apare, inclusiv
estimarea lor valorică, ca urmare a lipsei de informaŃii.
Echipa de proiectare poate determina o multitudine de indicatori cu privire la
informaŃiile totale, tipizate, netipizate şi suplimentare, vehiculate de sistemul existent, dintre
care menŃionăm:
• cheltuieli totale cu informaŃii tipizate, netipizate şi suplimentare
• cheltuieli necesare pentru utilizarea a 1000 informaŃii
• cheltuieli cu informaŃiile interne sau externe la 100 mil. RON producŃie marfă
• costuri medii de utilizare pe un anumit tip de document.
Această evaluare poate furniza conducerii unităŃii beneficiare elementele necesare
direcŃiei de perfecŃionare a actualului sistem şi operativitatea proiectării unui sistem
informatic.
112
3.7.6. Evaluarea variantelor de proiectare şi realizare a sistemului

informatic
Ea se realizează prin parcurgerea următoarelor faze:
• stabilirea funcŃiilor, cerinŃelor şi restricŃiilor viitorului sistem
• definirea soluŃiei globale de prelucrare automată a datelor
• evaluarea variantelor de realizare
1. Definirea funcŃiilor, cerinŃelor şi restricŃiilor viitorului sistem.

Ea se realizează pe evaluarea critică a sistemului ce a rezultat din fazele anterioare şi
pe obiectivele generale, cerinŃele şi condiŃiile formulate de conducerea unităŃii economice
beneficiare.
Pentru stabilirea funcŃiilor sistemului informatic este necesar a se determina aria şi
principalele activităŃi pe care trebuie să le scape sistemul informatic, inclusiv relaŃiile cu
subsistemele sau aplicaŃiile aflate deja în exploatare efectivă sau prevăzute a se realiza în
viitor. În urma stabilirii funcŃiilor globale ale viitorului sistem informatic, este nevoie a se
preciza cerinŃele generale ale viitorului sistem în raport de concluziile analizei sistemului
informaŃional existent. Pentru viitorul sistem informatic restricŃiile sunt deprinse de legislaŃia
economică şi reglementările interne aplicate de unitatea economică beneficiară, la care se pot
adăuga şi nivelul resurselor materiale şi financiare şi unitare de care dispune unitatea
analizată.
2. Stabilirea soluŃiei globale şi de principiu a sistemului informatic.

Ea are în vedere funcŃiile, cerinŃele şi restricŃiile anterior definite, prin stabilirea unora
sau mai multor soluŃii generale de organizare a prelucrării datelor de viitorul sistem
informaŃional. Fiecărei variante de utilizare i se stabileşte numărul activităŃilor şi gradul de
informatizare a acesteia prin delimitarea prelucrărilor ce se mai face automat, de cele ce se
vor face şi în continuare normal. Se vor preciza modificările previzibile cu structura şi
atribuŃiile preluate de către noul sistem informatic în raport cu cele ce vor rămâne în
exclusivitate în sarcina compartimentelor funcŃionale.
Având în vedere aceste opŃiuni cu caracter funcŃional se vor studia:
• soluŃiile tehnice de principiu cu referire la tipul de prelucrare (pe loturi sau
interactiv)
• tipul calculatorului (ce va fi în strânsă legătură cu dotarea existentă sau cea
prevăzută a se achiziŃiona)
• corelaŃia dintre volumul estimat al datelor de prelucrat şi capacitatea de stocare
a suporturilor de memorie externă disponibile
• posibilităŃile de utilizare a produselor program generalizabile sau reutilizabile
şi viteza de prelucrare a calculatorului
Aceste variante de realizare pot fi definite sub o formă globală prin identificarea
posibilităŃilor existente de proiectare a noului sistem în raport cu performanŃele şi limitele
caracteristice calculatorului ce urmează a fi folosit. Prin caracterul lor de anticipaŃie, aceste
variante demonstrează soluŃii de principii pentru proiectarea generală cu estimări sintetice şi
globale ale viziunii de ansamblu asupra modului de concepere şi proiectare a noului sistem.
3. Stabilirea variantelor de proiectare a noului sistem. Aceasta urmăreşte să

completeze funcŃionalitatea fiecărei variante cu o serie de informaŃii referitoare la costurile
implicate şi la efectele economice scontate, compararea permite conducerii unităŃii beneficiare
să evalueze varianta cea mai eficientă pe care se va baza proiectarea generală, proiectarea de
detaliu şi se va implementa sistemul informatic.
113
Variantele propuse vor fi estimate sub aspectul costurilor, efectelor economice,

modificările organizatorice în unitatea economică beneficiară, posibilităŃile de realizare
inclusiv termenele şi aspectele tehnice de introducere în exploatare efectivă a viitorului
sistem. Evaluarea costurilor, cuprinde cheltuielile prevăzute pentru proiectarea şi realizarea
sistemului informatic la care se adaugă cheltuielile necesare pentru exploatarea curentă.
Costurile permanente de funcŃionare se determină pe baza cheltuielilor cu amortizarea
calculatorului şi de comunicaŃie, amortizarea localului, cheltuieli cu întreŃinerea
calculatorului, salariile personalului, inclusiv CAS, cheltuielile cu materialele (hârtia de
imprimantă, etc.), cheltuieli cu energia electrică, etc.
Evaluarea efectelor economice este regăsită în urma aplicării fiecărei variante şi ea
poate fi: cuantificabilă şi necuantificabilă.
Cele cuantificabile, sunt economiile realizate prin redistribuirea personalului,
reducerea costurilor de producŃie, creşterea gradului de utilizare a capacităŃilor de producŃie
reducerea stocurilor de valori materiale, optimizarea fabricaŃiei, etc.
Cele necuantificabile reprezintă avantajeze obŃinute prin reducerea timpului de
răspuns, obŃinerea mai rapidă a rezultatelor, simplificarea circuitelor şi procedurilor
informaŃionale, asistarea procesului decizional, etc.
Stabilirea modificărilor organizatorice ale unităŃii, se referă la unele schimbări ce vor
interveni în compartimentele funcŃionale ce urmează instalării terminalelor şi imprimantelor,
ce vor asigura introducerea datelor din documentele de intrare pentru constituirea bazei de
date a sistemului informatic, eliminarea unor erori de prelucrare prin transpunerea pe diferite
alte suporturi, obŃinerea şi interpretarea situaŃiilor de ieşire obŃinute la imprimantă.
Stabilirea posibilităŃilor de realizare cuprinde unele elemente legate de preocuparea şi
asigurarea echipamentului tehnic de prelucrare şi transmitere a datelor, produsele program
utile şi posibilitatea obŃinerii lor precum şi personalul de specialitate necesar.
Stabilirea termenelor de realizare are ca scop elaborarea etapelor de proiectare a
noului sistem program şi a momentului de achiziŃionare a sistemelor electronice de calcul
necesare pentru conceperea şi implementarea unui sistem informatic. Ea trebuie să precizeze
termenele şi intervalele de perfecŃionare profesională a membrilor din compartimentele
implicate şi a personalului din unitatea proprie.
Colectivul de conducere al unităŃii beneficiare va evalua şi selecta varianta cea mai
eficientă a noului sistem pe baza concluziilor desprinse din evoluarea critică a întregului
sistem informaŃional analizat, prin luarea în considerare a tuturor variantelor de realizare
propuse şi prin consultarea unor specialişti în analiza şi realizarea sistemelor informatice cu
baze de date.
3.8. Finalizarea analizei sistemului actual

Ea presupune definitivarea documentaŃiei, urmată de avizarea acestei faze de către
colectivul de conducere al unităŃii beneficiare şi apoi trecerea de etapa de proiectare generală.
3.8.1. DocumentaŃia analizei sistemului actual

Ea are ca scop consemnarea într-o formă sistematizată şi sintetică a rezultatelor
analizei efectuate şi datele ce cuantifică volumul prelucrărilor aferente funcŃionării sistemului
informaŃional actual, astfel ca să permită formularea de aprecieri critice şi să furnizeze etapei
de proiectare generală unele elemente cantitative şi calitative necesare conceperii de ansamblu
pentru noul sistem informatic. Această documentaŃie cuprinde în mod obligatoriu următoarele
tipuri de documente: Organigrama structurii organizatorice ale beneficiarului, ActivităŃi şi
114
mijloace de calcul existente în unitate, Organigrama fluxului informaŃional, Descrierea

documentelor existente, Descrierea codurilor existente. CorelaŃia dintre aceste documente
specifice analizei sistemului actual şi succesiunea de utilizare este prezentată în figura 2.7.
ORGANIGRAMA
STRUCTURII
ORGANIZATORICE
ACTIVITĂłI
DOCUMENTE ŞI MIJLOACE DE
BENEFICIAR CALCUL
ORGANIGRAMA
FLUXULUI
INFORMAłIONAL
DESCRIERE DOCUM.
EXISTENTE
DESCRIERE CODURI
EXISTENTE
EVALUARE VARIANTE DE
CRITICĂ REALIZARE
Figura 3.10 CorelaŃia documentelor de analiză a actualului sistem [44]
3.8.2. Avizarea analizei actualului sistem

Se face de către colectivul de conducere al unităŃii beneficiare, într-o şedinŃă de
sesizare tehnico-economică la care participă reprezentanŃii echipei de proiectare,
compartimentele funcŃionale şi sectoarele de producŃie ale unităŃii. În această şedinŃă se
dezbat concluziile analizei şi evaluării critice ale actualului sistem şi se prezintă
caracteristicile soluŃiei de realizare a sistemului informatic care s-a considerat că întruneşte
cele mai multe avantaje şi criteriile de eficienŃă economică. Această avizare este urmată de
întocmirea unui PROCES-VERBAL DE AVIZARE, pe baza căruia se face decontarea
activităŃii desfăşurate pentru analiza actualului sistem în urma căruia se stabilesc măsurile
necesare trecerii la etapa de proiectare generală a sistemului informatic.

1. Care sunt părŃile analizei-diagnostic?
2. EnumeraŃi scopurile analizei-diagnostic informaŃionale.
3. Care sunt etapele analizei-diagnostic?
4. Ce conŃine raportul analiză-diagnostic informaŃionale?
5. Ce informaŃii oferă tehnica analizei celulare?
115
6. Care sunt etapele analizei celulare?

7. Care sunt scopurile analizei celulare?
8. Ce structuri de celule se pot întâlni?
9. Care sunt paşii de realizare a analizei celulare?
10. Care sunt cerinŃele proiectării sistemelor informatice?
11. Ce diagrame se pot folosi pentru descrierea sistemelor?
12. Ce simboluri foloseşte tehnica Gane?
13. Care sunt regulile sintactice de verificare a diagramelor cu softul?
14. Care sunt aspectele importante în timpul analizei cu DFD?
15. Ce aspecte pot releva DFD -urile?
16. Care sunt paşii AOO (Analizei Orientate Obiect)?
17. Care sunt tipurile de colective de analiză a sistemului existent?
18. DefiniŃi interviul.
19. Care este structura tipologică a unui interviu?
20. Ce metode de intervievare avem?
21. Care este structura interviului?
22. Ce fel de întrebări se folosesc la interviu?
23. Ce paşi se recomandă în proiectarea chestionarului?
24. Ce tipuri de eşantioane se folosesc la chestionare?
25. Ce caracteristici au grupurile folosite la intervievarea lor?
26. Ce elemente apar după analiza documentelor?
27. Care sunt elementele studiate în sistemul existent?
28. Care sunt cheltuielile actualului sistem?
29. Cine participă la sesiunile JAD?
30. Care sunt etapele de realizare ale prototipizării?
31. Ce sisteme se pretează la prototipizare?
32. Pe ce actori se bazează RAD?
33. De ce elemente depind reuşita RAD.
34. Care sunt etapele ciclului de viaŃă pentru RAD?
35. Care sunt principiile metodei XP?
36. Care sunt fazele metodei XP?
37. Prin ce se apreciază calitatea informaŃiei?
38. Prin ce faze se face evaluarea variantelor de proiect a sistemelor?
39. Ce documente sunt folosite în înlocuirea documentelor analizei sistemului actual?
116
4.
Capitolul
4 Proiectare şi specificaŃii
Cu ajutorul sistemul informatic se încearcă să se obŃină informaŃie activă.

Sistemul informatic integrat specific unor activităŃi, este sistemul ce asigură
introducerea unică a datelor şi prelucrarea multiplă a acestora în funcŃie de cele mai diverse
cerinŃe formulate de utilizatori.
Tehnologia informaŃiei (IT), este un termen contemporan care descrie combinaŃia de
tehnologii de calcul cu tehnologia comunicaŃiei.
Aceste sisteme au un ciclu de existenŃă specific, ce începe din momentul încheierii
contractului de proiectare şi realizare, încheindu-se în momentul când acest sistem va fi
înlocuit cu un alt sistem ce este caracterizat prin performanŃe superioare.
Pentru acest ciclu se disting două perioade principale [21] [44]:
• proiectarea şi realizarea sistemului informatic
• exploatarea sistemului informatic
Prima perioadă este acea parte a ciclului de existenŃă în care se concepe sistemul
informatic, se realizează programele aferente şi se elaborează documentaŃia de proiectare,
exploatare şi întreŃinere, în vederea punerii în funcŃiune la unitatea beneficiară.
A doua perioadă este acea parte a ciclului de existenŃă, ce asigură utilizarea efectivă a
sistemului prin prelucrarea automată a datelor din unitatea economică beneficiară.
Proiectarea şi realizarea sistemelor informatice este oportună în cazul sistemelor
informatice noi sau pentru dezvoltarea, modernizarea sau întreŃinerea celor existente.
În cazul proiectării, echipa de elaborare a sistemului informatic trebuie să parcurgă
următoarele procese de modelare succesivă:
• modelarea informaŃională – ce asigură descrierea critică a sistemului existent
şi defineşte cerinŃele funcŃionale cuantificate prin obiectivele la care urmează
să răspundă noul sistem informatic;
• modelarea conceptuală – ce descrie structura şi soluŃia funcŃională a noului
sistem în vederea satisfacerii în condiŃii cât mai bune a obiectivelor solicitate,
independent de un calculator, sistem de operare sau sistem de gestiune al
datelor;
• modelarea tehnică sau de detaliu – ce presupune transformarea soluŃiei
funcŃionale într-o soluŃie operaŃională pe un anumit tip de calculator, un anumit
sistem de gestiune al datelor, etc.
Nu este greu de înŃeles că realizarea unui sistem informatic sau doar a unei aplicaŃii,
presupune modelarea situaŃiei reale şi utilizarea modelului creat, în realitatea cu care operează
calculatorul.
Modelarea este reprezentarea într-un mediu controlat, a proprietăŃilor şi/sau
fenomenelor şi proceselor care caracterizează un obiect sau un sistem real. Cu alte cuvinte în
modelare nu există adevăr absolut; modelarea presupune abstracŃie şi aducerea în atenŃie
117
numai a unor aspecte ale realităŃii studiate şi anume acele aspecte care prezintă interes pentru
modelator. Unul din mediile controlate în care se poate reproduce realitatea, deci unul în care
se pot face modele, este calculatorul şi pe calculator se realizează modele informaŃionale. La
crearea modelului intervine viziunea analistului despre realitatea pe care o studiază, adică
paradigma. Paradigma reprezintă "ochelarii" prin care analistul vede sistemul informaŃional
real, acela pe care vrea să-l modeleze, dar nu toate viziunile sau concepŃiile analiştilor ajung
să fie considerate paradigme. La începuturile existenŃei sistemelor informatice, atenŃia
analiştilor a fost concentrată spre latura funcŃională a activităŃii umane studiate şi cum o
funcŃie a unui birou sau secŃie nu putea fi analizată şi nici prelucrată în bloc, ea a fost
descompusă în activităŃi (rezultând aplicaŃiile informatice), activităŃile au fost descompuse în
subactivităŃi (rezultând procedurile), care la rândul lor au fost descompuse în operaŃii, cărora
în calculator le corespundeau modulele program. S-a dezvoltat în aceste condiŃii o abordare
funcŃională a sistemelor informaŃionale. În informatica industrială funcŃiei îi corespunde
procesul, ceea ce a dus la abordarea orientată spre proces. Ulterior, locul fişierelor a fost luat
de bazele de date şi corespunzător, locul sistemelor de gestiune a fişierelor a fost luat de
sistemele de gestiune a bazelor de date (SGBD). Pe parcursul perfecŃionării SGBD -urilor, s-a
trecut la baze de date relaŃionale, creându-se impresia că elementul principal pe baza căruia
trebuie perfecŃionate SGBD -urile îl reprezintă structura datelor. Avem astfel de a face cu o
abordare orientată spre date. Când s-a pus problema aplicaŃiilor în timp real, factorul cel mai
important se părea a fi evenimentul. A apărut astfel orientarea spre evenimente.
Structurarea programelor a evoluat şi ea odată cu metodele de analiză, dar era din ce în
ce mai greu de Ńinut pasul cu metoda de analiză, mai exact cu orientarea abordării sistemelor
informatice. Preocupările analiştilor-programatori pentru a pune în concordanŃă structura
programelor cu metoda de analiză a sugerat o nouă abordare şi anume legarea evenimentelor
de obiect şi a programelor (numite de astă dată metode) de evenimente.
A apărut astfel orientarea pe obiecte, numai că spre deosebire de celelalte abordări,
ea se extinde şi în alte domenii de activitate, devenind un mod de a concepe realitatea,
adică o paradigmă. Dată fiind complexitatea sistemelor informatice ele nu se pot obŃine dintr-
odată şi nici nu se pot realiza după cum crede fiecare programator. Desigur la început aşa a
fost, dar pe măsură ce s-a acumulat experienŃă, ea a fost materializată în metodologii.
Metodologia elaborării sistemelor informatice a fost concepută iniŃial ca un ansamblu
de principii şi indicaŃii, tehnici şi metode grupate şi ordonate ca să ducă la realizarea
sistemului informatic. Cuvântul “metodă” folosit în această definiŃie nu are nimic de a face cu
metoda-program asociată evenimentelor unui obiect şi nici cu metoda de abordare a
sistemelor informaŃionale. Aici prin metodă se înŃelege un set de reguli aplicabile unui
domeniu restrâns din cadrul unei metodologii. In prezent metodologia este văzută ca setul
finit, particular definitoriu al unei metode (metodă de abordare a sistemelor informatice), prin
intermediul unui sistem coerent de formulare şi/sau procese informatice, necesare pentru
modelarea şi formalizarea totală a unui sistem informatic.
Metodologiile evoluează odată cu tehnologia informaŃiei, dar o metodologie de
realizare a sistemelor informatice trebuie să cuprindă [4] [21]:
• etapele/procesele de realizare a unui sistem informatic structurate în subetape,
activităŃi sarcini precum şi conŃinutul lor
• fluxul realizării acestor etape sau procese, subetape şi activităŃi
• modalitatea de derulare a ciclului de viaŃă a sistemului informatic
• modul de abordare a sistemului
• strategiile de lucru/metodele de realizare
• regulile de formalizare a componentelor sistemului informatic
• tehnicile, procedurile, instrumentele, normele şi standardele utilizate
118
Etapele de bază ale proiectării şi structurarea sistemelor informatice
• modalităŃile de conducere a proiectului (planificare, programare, urmărire) şi

modul de utilizare a resurselor financiare, umane şi materiale
În legătură cu sistemele informatice se mai folosesc două noŃiuni şi anume:
• Ciclul de viaŃă al dezvoltării sistemelor (CVDS) – se extinde pe intervalul de
timp cuprins între decizia de elaborare a sistemului informatic şi decizia de
abandonare sau de înlocuire cu alt sistem informatic.
• Ciclul de dezvoltare a sistemului informatic – se extinde de la decizia de
elaborare a sistemului informatic până la momentul intrării sistemului în
exploatare.
Metodologia de proiectare a sistemelor informatice îi sunt caracteristice următoarele
cerinŃe [7] [21]:
• procesul de realizare – ce este constituit dintr-un ansamblu de etape, faze,
activităŃi şi operaŃii
• metoda de realizare – ce constă din concepte şi reguli pentru aplicarea cărora
se poate concepe şi realiza sistemul informatic
• tehnica de realizare – ce este compusă dintr-un ansamblu de reguli
compatibile una cu alta, sau mai multe metode ce ghidează şi concură la
desfăşurarea etapelor, fazelor, activităŃilor şi operaŃiilor în cadrul unui proces
de realizare
• instrumentele de realizare – ce sunt formate din produse programe specifice
destinate automatizării unor activităŃi sau operaŃii de proiectare sau asistării
colectivului de proiectare în rezolvarea problemelor
4.1. Etapele de bază ale proiectării şi structurarea sistemelor

informatice
Cadrul metodologic specific sistemelor informatice din domeniul economic se bazează
pe un proces de realizare progresivă şi evolutivă structurat în etape ca: analiza sistemului
existent; proiectarea generală a noului sistem; proiectarea de detaliu a noului sistem;
implementarea sistemului proiectat; exploatarea curentă şi menŃinerea în funcŃie a noului
sistem. În fiecare etapă avem obiective, rezolvări şi rezultate proprii, ce au caracter
intermediar în procesul de asamblare al realizării sistemului informatic şi este compus din
faze şi activităŃi specifice, ce sunt concretizate într-o documentaŃie adecvată.
În realizarea sistemelor informatice se au în vedere etape ca:
Analiza sistemului existent. A fost descrisă în capitolul anterior.
Proiectarea generală a noului sistem. Aceasta asigură modelul conceptual al
noului sistem şi are ca obiect strategii elaborarea concepŃiei logice definită din punct de
vedere structural, cu stabilirea componentelor sale (subsisteme, aplicaŃie, unităŃi funcŃionale
şi unităŃi de prelucrare) a legăturilor dintre aceasta şi a funcŃionalităŃii structurii sale pentru
a se asigura omogenitatea şi eficienŃa proiectării. Ea se desfăşoară în mai multe faze, prin care
se definesc obiectivele noului sistem, se stabileşte conŃinutul şi structura bazei informaŃionale,
se stabilesc algoritmi atributelor de intrare şi este proiectată organigrama noului sistem.
Proiectarea de detaliu a noului sistem. Ea este acea etapă de modelare tehnică, cu
ajutorul căreia soluŃia conceptuală devine operaŃională în concordanŃă cu un sistem de
gestiune al datelor şi un calculator. Ea se subdivide în proiectarea de detaliu a unităŃilor
funcŃionale şi proiectarea de detaliu a unităŃilor de prelucrare, în funcŃie de specificul şi gradul
de detaliere corespunzător fiecărei substructuri.
Implementarea sistemului proiectat. Ea grupează activităŃile prin care sistemul
proiectat şi realizat fizic în cadrul etapelor parcurse anterior este verificat în condiŃiile reale
119
din unitatea beneficiară până la punerea în funcŃiune. Implementarea începe prin pregătirea
condiŃiilor pentru trecerea în exploatare a noului sistem, fiind urmată de testarea
funcŃionalităŃii sistemului şi evaluarea eficienŃei economice a acestuia, după care se
definitivează documentaŃia de utilizare şi exploatare.
Exploatarea curentă şi menŃinerea în funcŃiune a noului sistem. Aceasta include
activităŃi legate de utilizarea sistemului din unitatea beneficiară precum şi activităŃile de
perfecŃionare şi menŃinere în stare de funcŃionare a acestuia până la înlocuirea sa cu un alt
sistem informatic mai performant. Pentru abordarea şi rezolvarea etapizată a problemelor
specifice proiectării şi realizării sistemelor informatice, este necesară elaborarea unei scheme
structurale ce să asigure corespondenŃele dintre elementele componente ale unităŃii economice
şi componentele logice ale sistemului informatic.
Sistemul informatic, corespunde proceselor informaŃionale din sistemul obiect a căror
complexitate conduce la structurarea acestuia în componente interconectate logic denumite
subsisteme, aplicaŃii, unităŃi funcŃionale, unităŃi de prelucrare şi module.
Subsistemul informatic, grupează procesele informaŃionale omogene şi specifice unei
părŃi din sistemul obiect concretizate în activităŃi, atribute ale conducerii sau tehnologiei de
prelucrare a datelor.
AplicaŃia reprezintă o componentă a sistemului sau subsistemului informatic, care
rezolvă un grup omogen de lucrări sau probleme ale beneficiarului.
Unitatea funcŃională, reprezintă o componentă a sistemului sau a subsistemului sau o
aplicaŃie formată dintr-un grup de preliminări omogene funcŃional care acŃionează asupra unei
colecŃii sau subcolecŃii de date comune.
Unitatea de prelucrare, este componentă logică a unităŃii funcŃionale, ce este definită
de o secvenŃă de operaŃii automate şi repetitive prin intermediul unor opŃiuni de prelucrare
pentru transformarea mulŃimii datelor de intrare în mulŃimea datelor de ieşire în funcŃie de un
algoritm specific de prelucrare care are la bază un program generat şi activat de utilizator.
Modulul este o parte componentă a unităŃii de prelucrare şi este reprezentat de o
secvenŃă de instrucŃiuni sau comenzi de prelucrare declarate printr-un limbaj de programare
sau un sistem de gestiune al bazei de date în vederea rezolvării unei funcŃii independente din
algoritmul general specific unităŃii de prelucrare din care fac parte.
Cele prezentate anterior sunt redate de figura 4.1.
SISTEM
SUBSISTEMUL 1 SUBSISTEMUL i SUBSISTEMUL n
APLICAłIA i1 APLICAłIA ij APLICAłIA in
UNITATE F ij1 UNITATE F ijk UNITATE F ijm
UNITATE P ijk1 UNITATE P ijkl UNITATE P ikls
MODULUL ijkl1 MODULUL ijklh MODULUL ijklt
Figura 4.1 Structura unui sistem informatic [4]
120
Etapele de bază ale proiectării şi structurarea sistemelor informatice
Elementele de structurare prezentate servesc la proiectarea sistemelor informatice, atât

în varianta strategiei top-down (descendente) cât şi în varianta combinată dezvoltând şi
implementând distinct fiecare unitate funcŃională, în urma căreia se încheie proiectarea
generală.
4.1.1. Arhitectura sistemelor informatice

Arhitectura sistemului informatic reprezintă soluŃia generică privitoare la procesele de
prelucrare a datelor ce trebuie să se realizeze şi modul de integrare a datelor şi prelucrărilor.
Această soluŃie cadru este urmarea sintetizării răspunsurilor la următoarele întrebări:
• Care sunt componentele sistemului informatic?
• Cum sunt legate aceste componente şi cum interacŃionează ele?
• Ce date se culeg?
• Unde se culeg datele, unde se stochează şi prelucrează?
• Ce date se transmit către diferitele componente ale sistemului informatic?
Altfel spus, arhitectura reprezintă “soluŃia constructivă” a sistemului informatic şi
reflectă viziunea strategică managerială asupra modului în care organizaŃia (firma) lucrează.
Sistemul informatic global al firmei se descompune în subsisteme, fiecare dintre
acestea acoperind un domeniu de activitate distinct.
La rândul său, fiecare subsistem se descompune în aplicaŃii fiecare dintre acestea
acoperind o activitate distinctă în cadrul domeniului. De exemplu, subsistemul informatic
pentru domeniul comercial se va descompune în aplicaŃii distincte pentru fiecare din
următoarele activităŃi: aprovizionare, desfacere, marketing.
Procesul de descompunere continuă şi în pasul următor pentru fiecare aplicaŃie se vor
defini proceduri realizând funcŃii distincte în cadrul aplicaŃiei (exemplu: proceduri pentru
dirijarea prelucrărilor, proceduri pentru actualizarea bazei de date, proceduri pentru
consultarea bazei de date). La rândul lor, procedurile se descompun în module.
Acestea cuprind secvenŃe de cod realizând câte o funcŃie distinctă în cadrul procedurii.
De exemplu, o procedură de actualizare a bazei de date va cuprinde: un modul pentru
adăugare de înregistrări, un modul de modificare a tuplurilor, un modul de ştergere a
tuplurilor.
În definirea arhitecturii sistemului informatic s-au cristalizat în timp trei strategii [7]:
• Strategia descendentă.
• Strategia ascendentă.
• Strategia mixtă.
Strategia descendentă numită şi top-down pleacă de la principiul descompunerii
sistemului informatic complex în componente prezentând o complexitate mai redusă (definite
pe domenii de activitate de exemplu) parcurgându-se succesiv mai multe niveluri de detaliere
în cadrul fiecărei componente definite.
Prin această abordare, sistemul informatic dobândeşte o structură ierarhic modulară în
care fiecare componentă îndeplineşte o anumită funcŃionalitate şi va fi coordonată în
funcŃionarea sa de componentele plasate la nivelul ierarhic imediat superior.
Această strategie:
• se aplică în cazul sistemelor informatice complexe, vizând o arie largă de
cuprindere
• asigură realizarea unei soluŃii globale, unitare la nivel conceptual pentru
întregul sistem, componentele acestuia urmând să fie proiectate şi realizate
independent (pe baza unei planificări), priorităŃile fiind fixate în funcŃie de
121
opŃiunea beneficiarului sau importanŃei respectivelor componente şi

conexiunilor necesare în cadrul sistemului global
Pe măsura realizării componentelor din arhitectura generală a sistemului informatic
acestea se vor testa şi apoi integra în produsul final a cărui funcŃionalitate va fi de asemenea
verificată.
Impune un efort deosebit atât în perioada de analiză (fiind necesară o analiză
complexă şi foarte amănunŃită având în vedere complexitatea proceselor informaŃionale
supuse informatizării) cât şi de proiectare şi realizare ceea ce impune eforturi financiare
deosebite.
În procesul integrării componentelor nu vor apărea probleme deosebite ca urmare a
strategiei unitare de proiectare şi realizare definită la demararea proiectului.
Strategia ascendentă numită şi bottom-up promovează iniŃiativa la nivelul fiecărui
domeniu de gestiune (contabilitate, comercial, producŃie etc.) fără a exista o soluŃie cadru şi o
arhitectură definită pentru sistemul informatic global la nivel de organizaŃie.
Sistemele de gestiune se proiectează, realizează şi exploatează independent,
răspunzând cerinŃelor de gestiune ale domeniilor pentru care au fost realizate, urmând ca
ulterior să se treacă la integrarea acestora în cadrul sistemului informatic global al
organizaŃiei.
Datorită lipsei unei strategii unitare în plan hardware şi software, a unei soluŃii unitare
de proiectare şi realizare există riscul unui grad redus de integrare a subsistemelor de gestiune
realizate în cadrul sistemului informatic al organizaŃiei.
Strategia mixtă reprezintă o combinare a strategiei descendente cu strategia
ascendentă reŃinându-se punctele lor forte. În această abordare se optează pentru o definire a
componentelor sistemului informatic în conformitate cu cerinŃele strategiei descendente,
urmând ca proiectarea, realizarea şi integrarea acestor componente să se realizeze urmând
cerinŃele strategiei ascendente.
Indiferent de strategia utilizată în definirea arhitecturii trebuie ca această soluŃie să
permită dezvoltarea ulterioară a sistemului informatic prin crearea şi integrarea de noi
componente. O astfel de abordare conduce la definirea de arhitecturi deschise pentru
sistemele informatice.
Numai astfel sistemul informatic va putea evolua odată cu activitatea organizaŃiei
asigurând suportul informaŃional necesar procesului de conducere şi se va putea totodată
moderniza prin integrarea de noi soluŃii TI.
4.1.2. Arhitectura sistemului informatic al unei firme

Din prezentarea modului de definire a arhitecturii sistemului informatic a rezultat
faptul că efortul proiectanŃilor se focalizează asupra definirii principalelor componente ale
sistemului şi a interacŃiunilor dintre acestea astfel încât viitorul sistem să acopere cerinŃele
informaŃionale necesare procesului de conducere.
Odată definite componentele de bază ale sistemului informatic, descompunerea
succesivă a fiecăreia dintre acestea se va desfăşura în timp pe baza planului de realizare
stabilit în funcŃie de priorităŃi, importanŃa componentelor şi interacŃiunile existente între
acestea.
În figura următoare este prezentată în abordarea top-down o posibilă soluŃie pentru
arhitectura sistemului informatic al unei firme integrându-se în cadrul acesteia atât
componentele reprezentând subsistemele de management (MSS) cât şi cele operaŃionale
(OSS) şi de gestiune a cunoaşterii.
122
Modele de proiectare a sistemelor
SI
SISTEME INTERORGANIZAłIONALE
MSS OSS KWS
OAS TPS PCS

EI DSS MIS
CONTAB. COMERCIA PERSONAL CERCETAR PRODUCłIE

L E
FINAN- DE APROVI- DES- MARKE-

CIARĂ GESTIUNE ZIONARE FACERE TING
Figura 4.2 O posibilă soluŃie pentru arhitectura sistemului informatic al unei firme [21]
4.2. Modele de proiectare a sistemelor

Ciclul de viaŃă al dezvoltării sistemelor este o metodologie comună de dezvoltare a
sistemelor, ce se caracterizează prin câteva faze ce marchează evoluŃia efortului de analiză
proiectare. La începutul abordării sistemelor, numărul etapelor era de şase, care erau
descompuse pe activităŃi şi subactivităŃi. Trecerea la orientarea pe procese şi orientarea pe
date duce la generarea a două fenomene: diversificarea etapelor, revizuirea modelului sub care
se manifestă ciclicitatea.
TendinŃa de prelucrare a unor etape specifice managementului proiectării, poate fi:
• identificarea şi alegerea proiectului
• planificarea şi întreŃinerea proiectului, ce se numesc etape de micro
analiză
Ele vor precede analiza, proiectarea logică, proiectarea fizică implementarea şi
întreŃinerea. Uneori etapele se pot derula iterativ, alteori în cascadă sau chiar paralel. Putem
concluziona că, ciclul de viaŃă este pe o spirală sau are un proces circular. În cele ce urmează
vom prezenta unele din acestea.
4.2.1. Modelul în cascadă

Acesta este unul de referinŃă, asigurând trecerea de la o etapă la alta în ordine
secvenŃială. El a fost lansat în 1970, descompunând ciclul de viaŃă în faze secvenŃiale, fazele
fiind structurate pe activităŃi şi subactivităŃi.
Trecerea de la o etapă la alta se realizează după etapa precedentă a fost parcursă în
întregime. Modelul e redat de figura 4.3.
123
Fezabilitatea
sistemului
Validare
Planificare
a lucrărilor
Validare
Proiectare
generală
Verificare
Proiectare
de detaliu
Verificare
Scrierea
programelor Testarea
componentelor
Integrare
Verifică
Instalare
Testare
Exploatare
dezvoltare
Revalidare
Figura 4.3 Modelul cascadă [7]

Acest model are următoarele avantaje:
• controlul total asupra fazelor
• uşor de însuşit de membrii echipei de analiză proiectare
• fiecare fază este însoŃită de o documentaŃie completă.
El are următoarele dezavantaje:
• sistemul poate fi predat după parcurgerea etapelor, deci necesită timp mult
• nu corespunde intenŃiilor de abordare dinamică
• nu este deschis schimbărilor ce apar pe parcurs
124
4.2.2. Modelul prototipului rapid

Un prototip rapid este un model echivalent din punct de vedere funcŃional cu o
submulŃime a produsului.
De exemplu: dacă produsul Ńintă trebuie să se ocupe cu facturile plătite, primite,
arhivate atunci acest model constă într-un produs care facilitează modul de afişare şi tipărire
al raporturilor, dar nu corectează greşelile de manipulare a datelor.
Primul pas al acestui model este de a construi un prototip rapid şi de a lăsa clientul şi
viitorii utilizatori să interacŃioneze cu el.
O dată ce clientul este satisfăcut şi prototipul face tot ceea ce el cere producătorii pun
la punct documentaŃia cu o anumită garanŃie că produsul răspunde cerinŃelor clientului.
Un punct puternic al acestui model este faptul că dezvoltarea produsului este lineară
începând cu prototipul rapid şi terminând cu produsul livrat. Inelele de feedback de la
modelul cascadă nu mai sunt necesare aici.
Există numeroase motive pentru acest lucru: membrii echipei folosesc prototipul rapid
pentru a pune la punct documentaŃia de specificaŃie. În faza de design datorită creării
prototipului rapid echipa află de cele mai multe ori o varietate de ”cum să nu se facă
produsul”.
Următoarea fază este implementarea, când se diminuează comparativ cu modelul
cascadă, nevoia de a corecta greşelile de proiectare. După ce produsul a fost acceptat de client
urmează faza de păstrare şi ciclul reîncepe de la cerinŃe, specificaŃii, design sau implementare.
Un aspect esenŃial al acestui model este conŃinut în cuvântul rapid.
Scopul acestui model este de a afla adevăratele nevoi ale clientului, iar structura
internă a modelului nu este relevantă. Ceea ce este important este că prototipul să fie construit
şi modificat rapid, viteza este esenŃială.
4.2.2.1. Integrarea modelului cascadă şi a prototipului rapid

În ciuda multelor succese pe care le-a avut modelul cascadă, a avut şi un mare
dezavantaj prin faptul că ceea ce era livrat clientului nu era cea ce acesta îşi dorea şi modelul
prototipului rapid a avut multe succese, cu toate că nu a fost dovedit fără nici o îndoială şi
poate avea unele scăpări.
O soluŃie ar putea fi combinarea celor două abordări. Prototipul rapid poate fi utilizat
ca o tehnică de analizare a cerinŃelor, cu alte cuvinte, primul pas este construirea unui prototip
rapid şi apoi folosirea acestuia în modelul cascadă.
Apare un efect secundar datorită riscului în folosirea noii tehnologii. Introducerea unui
prototip rapid în proiecte ca şi punct de plecare pentru modelul cascadă va da conducerii
oportunitate de a evalua tehnica o dată cu minimizarea riscului asociat.
4.2.3. Modelul V
Acesta este o variantă a precedentului, prin care se introduc concepte de sisteme şi
componente (subsisteme), aplicându-se teste explicite la un sistem ierarhic pentru creşterea
controlului asupra modului în care se desfăşoară etapele.
Această înlesnire constituie o latură a literei V. Latura stângă este parcursă
descendent şi conŃine etapele propriu-zise, iar cea dreapta se parcurge ascendent şi realizează
verificările ascendente, realizându-se verificările şi validările elementelor create anterior.
Acest model este dat de figura 4.4.
125
Realitate
ÎntreŃinere
IniŃierea Specificarea Ieşire fază

proiectul cerinŃelor EvoluŃie
finală
Sistem
testat Software
Specificarea SpecificaŃie verificat Acceptare
detaliată a (inclusiv
cererilor acceptare)
Proiectarea Integrarea şi
arhitecturii testarea sis-
sistemului temului
Software
testat
Software
Proiect integral
analiza Proiectarea de Integrarea şi analiza

calităŃii detaliu testarea calităŃii
software
Module
testate
Module Module
proiectate depanate
Codificarea şi testarea
componentelor
Figura 4.4 Modelul V

Modelul punctează cu claritate separările dintre ceea ce implică participarea
utilizatorului. Arhitectura sistemului este surprinsă la mijlocul literei, iar partea inferioară a ei
se referă la implementare.
Modelul se reprezintă şi pentru mediul orientat pe obiecte, fiind-că încurajează
prototipurile şi reutilizarea unor structuri superioare.
Acest model face distincŃie evidentă între verificare şi validare.
4.2.4. Modelul W
Acest model reia ideea modelului în V pe care îl dezvoltă şi perfecŃionează prin
integrarea activităŃilor de validare la nivelul fazelor de proiectare.
126
Test de
SpecificaŃii
acceptare
Definirea Proiectarea Testarea

Machete
cerinŃelor sistemului sistemului
Proiectarea Proiectarea Testarea

de nivel înalt componentei i componentei
Verificarea flux Realizarea

- urilor logice componentei i
Figura 4.5 Reprezintă modelul în W

(sursă: Chantal Morley – Gestion d’un projet système d’information)
4.2.5. Modelul incrementat

Acesta este o altă formă a celui în cascadă, deoarece partea de început nu are nici o
diferenŃă de modelul în cascadă, apoi se efectuează descompunerea proiectului în subproiecte,
ele fiind urmărite pe activităŃi care vor concura la obŃinerea componentelor necesare
sistemului final.
FaŃă de modelul V, acesta oferă posibilitatea atingerii scopului final în două variante:
sistemul global la sfârşit sau componente livrate distinct, conform figurii 4.5.
• este încadrat în principiul “divide et impera”, cu posibilitatea abordării unor
părŃi ale sistemului
• sistemul poate fi livrat şi pe componente realizate la perioade scurte de timp
• proiectul poate fi livrat şi pe componente realizate la perioade scurte de timp
• proiectul sau sistemul final poate fi realizat de mai multe echipe sau persoane,
datorită modularizării sale
El are următoare dezavantaje:
• imposibilitatea aplicării lui în toate cazurile, uneori necesitând elementele
descompunerii întregului
• componentele pot fi realizate numai după ce întregul sistem i se defineşte
arhitectura, totul dezvăluindu-se după principiile metodelor top-down, ceea ce
înseamnă o condiŃie dură, cunoaşterea şi formularea cerinŃelor din faza
incipientă de abordare a sistemului
• se poate realiza pe părŃi, eforturile de integrare a acestora în întreg, sunt mari,
cu trimitere la faptul că de fiecare dată la adăugare de noi componente,
sistemul poate fi considerat unul nou
127
Fezabilitatea
sistemului
CerinŃele
sistemului
Proiectarea arhitecturii
sistemului
iteraŃia 1 iteraŃia 2 iteraŃia n

Proiectarea Proiectarea Proiectarea
de detaliu de detaliu de detaliu
Realizare, Realizare, Realizare,

Testare Testare Testare
Integrare Integrare Integrare
Implementare Implementare Implementare

(instalare (instalare (instalare
componentă) componentă) componentă)
ÎntreŃinere/ ÎntreŃinere/ ÎntreŃinere/

revalidare revalidare revalidare
Figura 4.6 Modelul incrementat
4.2.6. Modelul spirală

Acesta este lansat în anii 81-86, bazându-se pe două convingeri:
• natura iterativă a dezvoltării şi nevoia de planificare şi evaluare a riscurilor
fiecărei iteraŃii;
• deficienŃa înregistrată la modelul V, unde validarea este efectuată prea târziu şi
realizarea cât mai devreme posibil, de cât mai multe ori, prin constituirea
prototipurilor, conform figurii 4.7.
Validarea se efectuează prea târziu şi se realizează cât mai devreme posibil, făcându-
se de ori decât ori este necesar, prin constituirea prototipurilor, conform figuri 4.7.
128
Costuri cumulate,
parcurgerea etapelor Evaluarea
Determinarea
obiectivelor, alternativelor,
alternativelor, identificarea şi
restricŃiilor Analiza soluŃionarea riscurilor
riscurilor
Analiza
riscurilor
Analiza Prototip
riscurilor opera-
Ńional
Ana Pro-
liza totip
ris - Pro- Pro- 3
curi totip totip
lor 1 2
CerinŃe de planificare. Simulări

Planificarea ciclului modele
Conceptul evaluări
de viaŃă operării CerinŃele
produsului
Plan de soft Proiec-
dezvoltare Validarea tarea SI Proiectarea
cerinŃelor de detaliu
Codi-
Planul de Validarea Test ficare
integrare şi proiectării şi com-
testare verificare ponen-
Planificarea Inte- tă
fazelor următoare Accep- grare
Imple- şi test
tare
mentare
testare Dezvoltarea,
verificarea
următorului nivel
Figura 4.7 Modelul spirală [21]

• posibilitatea evaluării riscurilor în diferite momente;
• simplificarea operaŃiunilor de evaluare a ceea ce este necesar prototipurilor în
acea etapă.
Ea are următoarele dezavantaje:
• echipa trebuie să fie profesionistă;
• fluxurile în acŃiune, inclusiv alocarea de fonduri, dar şi definirea activităŃilor
de întreprins.
4.2.7. Modelul X
El extinde aria performanŃelor obŃinute prin modelele cascadă şi V, care sunt
considerate exemple ale procesului de dezvoltare.
Modelele livrării sunt independente tehnologic, iar impactul orientării pe obiect asupra
procesului dezvoltării tradiŃionale, cu specificaŃii ale sistemului, proiectul arhitectural,
proiectarea de detaliu, codificarea, testarea pe componente, integrarea şi testarea sistemului.
129
Latura inferioară a modelului X, este un V întors, pentru sugerarea noŃiunii de

gestiune patrimonială a depozitelor reutilizabile, fie la nivel de componentă, de structura
domeniului sau chiar la nivel de aplicaŃie.
Modelul X exprimă două mari categorii de cicluri de activităŃi: una se derulează
înainte (forward activity) şi care sintetizează noul sistem sau îl modifică, altă activitate
derulată înapoi (reverse activity) pentru dobândirea sistemelor şi a componentelor lor,
catalogarea diverselor modele, arhitecturi şi componente ale activităŃii, finalizându-se cu o
posibilă reutilizare.
Modelul X de dezvoltare a softului va lua în considerare existenŃa diferitelor cicluri de
viaŃă concurente aplicaŃiei şi proiecte abstracte, conŃinutul bibliotecilor, iar componentele
fizice se află într-un continuu proces de rafinare.
Nici acest model nu va ocupa un loc de seamă în categoria modelelor, deoarece nu
aduce elemente noi, ci doar surprinde în detaliu V întors, ceea ce în realitate se face şi de alte
metode, iar partea superioară a modelului X este o reluare grosolană a modelului V.
4.2.8. Modelul pinball

Principiul modelului este cel al deplasării aleatoare a unei bile împinse printr-un
sistem mecanic cu arc sau electronic, cu simularea mişcărilor mecanice în vederea atingerii
unei Ńinte punctate diferit. Uneori deplasarea bilei depinde şi de acŃiunile întreprinse de
jucător. Pentru sistemele orientate pe obiect, aflarea clasei de apartenenŃă a atributelor,
metodelor, relaŃiilor dintre obiecte, definirea colaborărilor, moştenirea, agregarea şi
subsistemele, precum şi convertirea proiectului în instrucŃiuni, cu testarea şi implementarea
lor. Analogia constă în faptul că deplasarea bilei în interiorul panoului într-un mod repetat
aleator, semănând cu ce se întâmplă în ciclul de viaŃa al obiectelor. Conform figurii
următoare:
I
N
I Definirea Găsirea Definirea I
agregărilor claselor subsistemelor ł
M I
P E
L Definirea Aflarea R
E metodelor E
atributelor A
M
E P
Definirea Identificarea Definirea R
N moştenirilor
colaborărilor relaŃiilor O
T I
A E
R C
Codificare Testarea T
E U
A L
U
I
Figura 4.8 Modelul pinball [21]
4.2.9. Modelul fântână arteziană

El îşi are originea în modelul spirală şi în altele ce au reprezentat o îmbunătăŃirea a
acestuia, de aceea nu prezentăm alte detalii, ci dăm un exemplu grafic de unul tip vârtej de
apă, conform figuri 4.9.
130
ÎntreŃinere Utilizare Dezvoltare
Testarea sistemului
Testare componentă
Codificare
Proiectare componentă
Proiectare sistem
SpecificaŃii privind
cerinŃele software
SpecificaŃii ale
cerinŃelor utilizatorului
Analiză
Lumea reală
Figura 4.9 Modelul fântână arteziană [44]
4.2.10. Modelul dezvoltării concurente (a mingii de baseball)

Acesta este caracterizat de aspecte ca:
• renunŃarea la paşi în favoarea activităŃilor
• dezvoltarea concurentă
• echipe interdisciplinare
• rezultate controlate frecvent, deci, măsurabile
În acest model analiza orientată pe obiect şi proiectarea orientată pe obiect, sunt
activităŃi ce se desfăşoară, nu paşi, care se pot realiza în paralel.
Aici o echipă efectuează în sistem concurenŃial, deci în paralel, activităŃile de analiză
orientate pe obiect, proiectarea orientată pe obiect şi programarea orientată pe obiect.
Echipa de proiectare trebuie să fie interdisciplinară şi care va lucra împreună la analiza
orientată pe obiect, proiectarea orientată pe obiect şi programarea obiectuală.
Analizând mai atent modelul putem observa că are o structură circulară bidirecŃională.
Această procedură determină analiza orientată pe obiect (OOA) să beneficieze de
rezultatele proiectării orientate pe obiect (OOD) şi a programării obiectuale (OOP). Acest
model se poate reprezenta grafic prin figura 4.10.
131
D00
A00
P00
Figura 4.10 Modelul dezvoltării concurente
4.2.11. Modelul piramidă

El scoate în relief faptul că succesiunea etapelor unui ciclu de viaŃă înseamnă şi
trecerea treptată spre mai multe detalii, pornindu-se de la nivelul superior al planificării firmei
vspre analiza domeniilor mari ale sale, proiectarea sistemului şi apoi constituirea lui, conform
figuri 4.11.
Planificarea firmei
Analiza domeniilor
Proiectare sistem
ConstrucŃie
Structură obiect
Figura 4.11 Modelul piramidă

Componentele lor sunt:
• planificarea firmei, cu:
- obiectivele firmei şi factorii de succes
- crearea unei imagini globale asupra firmei
- identificarea obiectelor firmei la nivel superior
• analiza domeniilor, cu:
- construirea unui model orientat pe obiect al domeniului firmei
- găsirea obiectelor domeniului economic
- găsirea evenimentelor şi operaŃiilor economice
- exprimarea politicilor economice ca reguli
• proiectare sistem, cu:
- crearea modelului orientat pe obiect al sistemului
- conceperea proiectului detaliat al claselor
132
- generarea prototipurilor pentru validarea lor de către utilizatori

• construcŃie, cu:
- implementare metode
- generarea codurilor program posibile
La nivelul superior se va construi modelul global al sistemului. O parte a sa se va
dezvolta în mai multe detalii la nivelul analizelor întreprinse cu domeniile de interes ale
firmei. Apoi o parte a modelului se dezvoltă în mai multe detalii la nivel de proiect de sistem.
După care urmează ca sistemul să se constituie în clase şi metode orientate pe obiect. Acelaşi
depozit este folosit la toate nivelurile şi se completează cu cât mai multe detalii posibile.
În urma descrierii principalelor modele ale ciclului de viaŃă al sistemului, putem trage
următoarele concluzii:
• metodele sunt diverse, după tehnologiile utilizate, necesarul de realizare al
sistemului, iar saltul considerabil este în mediul orientat pe obiect
• modelele depind de mărimea proiectului, dar şi de domeniile cărora le aparŃin
sistemele
• diferenŃele dintre modele constau în modul de parcurgere al etapelor, ca ordine
dar şi în ce priveşte modalitatea de abordare a sistemului
• la alegerea modelului un rol deosebit îl are echipa ce face această operaŃie,
făcând referire la experienŃa de a lucra cu aceste modele
• cerinŃele funcŃionale îşi pun amprenta pe tipul de model, deci se poate aborda
în totalitate sau pe componente funcŃionale
• complexitatea sistemului se va reflecta în mare măsură la alegerea modelului
• nivelul de implicare a utilizatorilor în realizarea sistemului va impune opŃiunea
pentru modelele cu performanŃe diferite în acest plan
Reprezentarea grafică a modelelor se face în figura 4.12.
Etape
Definire cerinŃe
Proiectare
Implementare
Instalare şi întreŃinere
Modele
Cascadă Incrementate Spirală Evolutiv
Figura 4.12 Reprezentarea grafică a modelelor

Putem concluziona că fiecare model prezintă câte ceva original sau pune anumite
probleme, lucru ce ne arată că acestea sunt perfectibile.
133
4.3. Raportul dintre cerinŃele sistemului şi alegerea variantei optime

de proiectare
Despre varianta noului sistem sunt o serie de incertitudini, generate de nehotărârea
sau, încă, neidentificarea asupra formei finale dorite. Pentru a ajunge la o concluzie finală
comună trebuie pornit de la cerinŃele structurale.
Rezultatul final de identificare a cerinŃelor de informaŃii se concretizează într-un raport
detaliat al cerinŃelor sistemului, unde se vor prezenta informaŃiile necesare noului sistem.
Raportul trebuie să cuprindă tot ce trebuie să producă noul sistem şi care va trebui să lase
fazei de proiectare o imagine calară a modului cum se obŃin cerinŃele (obiectivele) sistemului.
Raportul trebuie să cuprindă următoarele elemente:
• descrierea funcŃiilor principale executate de noul sistem
• descrierea tuturor datelor necesare noului sistem
• structura preliminară a datelor (organizarea şi legăturile lor)
• descrierea şi modelul fiecărei ieşiri din sistem
• descrierea şi prezentarea tuturor intrărilor în sistem
• volumul minim, mediu şi maxim de date determinându-se numărul de operaŃii
al intrărilor, al documentelor şi înregistrările stocate
• descrierea modului de funcŃionare a noului sistem şi a subsistemelor,
aplicaŃiilor componente
• descrierea normelor interne cu condiŃia privind raportările, programarea
activităŃilor, etc…
• prezentarea restricŃiilor existente în sistem;
• lista problemelor de politică curentă a firmei şi conflictele existente cu
beneficiarii şi modul lor de soluŃionare
• punctele de control a datelor ce asigură siguranŃa şi controlul realizării
operaŃiilor
• necesitatea reorganizării firmei pentru a răspunde cerinŃelor utilizatorilor
Pe lângă raport se va înainta o sinteză pentru conducere, fără să se apeleze la limbajul
tehnic, ca să se prezinte cerinŃele utilizatorilor şi efortul de elaborare a noului sistem. Raportul
trebuie să fie însoŃit de exemple de structuri ale înregistrărilor, de ieşiri, grafice, pe variantele
strategice propuse de proiect.
În urma acceptului utilizatorilor, conducerile implicate vor semna documentele
necesare aprobării rezultatelor fazei desfăşurate. Aceasta se finalizează cu raportul analizei de
sistem ce sintetizează şi documentează constatările făcute în această etapă.
Raportul va conŃine:
• scopul, domeniul, obiectivele şi restricŃiile proiectului
• legătura proiectului cu planul strategic al firmei
• criticile aduse sistemului de analişti
• sinteza problemelor existente în sistem şi restricŃiile acestuia
• recomandări de îmbunătăŃire a sistemului şi proiectarea noului sistem
• descrierea informaŃiilor necesare luării deciziilor
• sinteza tuturor studiilor de fezabilitate cu recomandarea ca sistemul să mai fie
sau nu
• estimarea timpului, a costurilor şi a resurselor necesare noului sistem
• planurile preliminare ale fazei de proiectare a sistemului
134
Modul de alegere al variantei optime şi tipuri de baze de date
Decizia de a se proiecta sau nu, se ia de trei ori în timpul analizei şi anume:

• la investigarea iniŃială pentru a se stabili dacă se va trece la studierea
sistemului
• la sfârşitul studiului de fezabilitate ca să se stabilească trecerea la etapa de
stabilire a necesarului de informaŃii
• la terminarea fazei de analiză, pentru a se stabili dacă se va trece la faza de
proiectare
4.4. Modul de alegere al variantei optime şi tipuri de baze de date

Se recomandă parcurgerea următorilor paşi:
• separarea cerinŃelor formulate în categorii distincte în funcŃie de performanŃele
urmărite
• prezentarea diferitelor medii potenŃiale de implementare
• propuneri diverse vizând căile de identificare a surselor sau modalităŃi de
procurare necesare atingerii performanŃelor dorite
Dacă există trei seturi de formulări ale cerinŃelor, trei medii de implementare şi patru
resurse ale softului de aplicaŃie, rezultă 36 de strategii posibile de proiectare.
Alegerea celei optime se efectuează cu ajutorul procedurilor cantitative, iar proiectul
poate fi oprit chiar acum de la executare.
Acum trebuie realizate următoarele activităŃi:
• prezentarea strategiilor posibile de proiectare
• alegerea unei strategii
• prezentarea planului de bază al proiectului pentru regăsirea strategiei alegerii
sistemul informaŃional în curs de realizare
4.4.1. Crearea variantelor strategice ale proiectului

Echipa de analiză trebuie să propună cel puŃin două soluŃii la problema suspusă
analizei, cel mai recomandat număr de soluŃii propuse de analişti este de trei. Prezentăm trei
variante de soluŃii.
Varianta 1. Ea este caracterizată astfel:
• este cea mai conservatoare în ceea ce priveşte costurile, efortul depus şi
tehnologia implicată
• de multe ori ea nu necesită folosirea calculatorului
• este orientată spre realizarea pe hârtie a fluxurilor informaŃionale mai eficiente
sau eliminarea redundanŃelor din procesele curente
• oferă toate cerinŃele utilizatorului, printr-un sistem care diferă puŃin de cel
existent
Varianta 2. Ea are următoarele caracteristici principale:
• orientarea spre funcŃionalitate
• costurile nu constituie problema cea mai importantă
• se oferă cele mai performante sisteme bazate pe cele mai avansate tehnologii
• sistemul este deschis unor posibile extensii viitoare
• utilizatorul este copleşit de variantă, dar nu întotdeauna poate să identifice o
astfel de variantă din cauza resurselor limitate
Varianta 3. Ea are următoarele caracteristici:
135
• combină trăsăturile celor două variante, renunŃând la obsesia încadrării în

anumite costuri şi preluând ca obiectiv controlul de funcŃionalitate de nivel
înalt
• este o variantă de compromis
Încadrarea în cele trei soluŃii se face cu o minuŃioasă analiză a cerinŃelor sistemului.
Cu informaŃiile culese, analiştii organizează sistematic cerinŃele sistemului.
4.4.2. Determinarea minimului necesar de informaŃii solicitate de noul

sistem
Determinarea informaŃiilor se realizează prin consultarea utilizatorilor şi a iniŃiatorilor
sistemului. Trăsăturile unui sistem se pot împărŃi în trei mari categorii, anume: obligatorii,
esenŃiale şi dorite.
Trăsăturile sistemului se concretizează în:
• datele reŃinute în sistem
• ieşirile sistemului
• analizele pe baza cărora se obŃin noi informaŃii
• accesibilitatea, timpul de răspuns, modul de exploatare
• stabilirea restricŃiilor din noul sistem
RestricŃiile pot fi create de următorii factori:
• un termen anume când sistemul trebuie schimbat
• resursele financiare şi umane disponibile
• elementele din sistemul curent ce nu pot fi schimbate
• restricŃiile impuse de cadrul legislativ sau de contracte
• importanŃa datelor şi dinamica problemei supuse analizei impun limite
referitoare la modul de realizare a sistemului
Ambele considerente trebuie să fie identificate şi ierarhizate după importanŃa lor.
4.4.3. Tipuri de baze de date şi caracteristicile proiectării lor

Varianta optimă de alegere a bazei de date presupune selectarea realizării unei singure
baze de date sau a mai multora în funcŃie de volumul datelor, complexitatea prelucrărilor şi
aria noului sistem informatic. Deci pentru un sistem informatic se pot lua în considerare patru
tipuri de baze de date:
• bază de date unică sau centrală pentru întregul sistem
• baze de date funcŃionale realizate pentru fiecare funcŃie a unităŃii beneficiară
• baze de date specifice unor domenii de activitate
• bază de date distribuită (combinată) ce are caracteristicile funcŃionale ale
celorlalte tipuri
Proiectarea acestor tipuri de bază de date se face în funcŃie de următoarele elemente:
• utilizarea unui model global al datelor şi a unui control centralizat al
prelucrărilor, indiferent de numărul bazelor de date proiectate
• stocarea datelor în una sau mai multe baze de date, ce trebuie să asigure
permanent utilizatorilor indiferent de gradul de distribuire al bazei
• coexistenŃa mai multor tipuri de baze de date care presupune interconexiunea
acestora într-o viziune unică astfel încât toate bazele de date să fie considerate
în mod generic ca o bază de date globală
• unitatea de administrare a datelor poate să fie general valabilă sau specifică
pentru variantele de bază de date
136
Planul de bază al proiectului
• consistenŃa, integritatea, securitatea şi controlul centralizat al redundanŃelor

datelor sunt comune pentru toate tipurile de date
Elementele prezentate sunt realizabile prin intermediul unui subsistem de administrare
al bazei de date (SABD) ce este o componentă logică cu funcŃia de administrare a întregului
complex al noului sistem informatic. Aceasta se află sub directa coordonare a
administratorului bazei de date, prin care se asigură dirijarea şi monitorizarea accesului
fiecărui subsistem informatic la baza de date.
Administratorul realizează următoarele funcŃii:
• monitorizarea şi organizarea accesului utilizatorului şi subsistemelor
informatice la baza de date sub controlul SGBD-ului
• crearea şi încărcarea iniŃială a bazei de date prin descrierea structurii schemei
bazei de date a subschemelor sale, precum şi validarea sintactică-semantică a
datelor de intrare
• întreŃinerea bazei de date, ce se realizează prin actualizarea datelor, salvarea şi
restaurarea bazei de date, iar la anumite intervale de timp se vor face
reorganizări şi restructurări ale sale
• evaluarea şi dezvoltarea performanŃelor de exploatare a întregului complex al
bazei de date, este făcut prin intermediul unor indicatori statistico-informatici
de urmărire a mecanismului de funcŃionare al acesteia privit ca un tot unitar
În urma alegerii soluŃiei optime de proiectare a noului sistem informatic se trece la
proiectarea de detaliu a acestuia.
4.5. Planul de bază al proiectului

În urma parcurgerii activităŃilor precedente, ce finalizează alegerea variante de
implementat, deci planul proiectului primeşte alte dimensiuni, iar în practică numele de
Planul de bază al proiectului.
Planul trebuie să aibă următoarea structură:
1. Introducere
1.1. Prezentarea generală a proiectului
1.2. Recomandări
2. Descrierea sistemului
2.1. Prezentarea succintă a variantelor
2.2. Descrierea sistemului
3. Studiile de fezabilitate
3.1. Analize economice de cost şi beneficiu
3.2. Analize tehnice
3.3. Analiză operaŃională
3.4. Analiza legalităŃii şi a contractelor
3.5. Analiza politicilor firmei
3.6. Analiza desfăşurării calendaristice
4. Probleme de management
4.1. ConfiguraŃia şi managementul echipei
4.2. Planul comunicării echipei cu beneficiarul
4.3. Standardele şi procedurile proiectului
4.4. Alte aspecte specifice proiectului
Planul reprezintă punctul iniŃial al dezvoltării proiectului, dar componentele celor
patru capitole pot fi amendate pe parcursul întregului ciclu de viaŃă a proiectului.
137
4.6. Stabilirea obiectivelor sistemului informatic

Obiectivele constituie scopuri imediate şi de perspectivă ale perfecŃionării activităŃii
economice şi de conducere, pentru ridicarea nivelului de informare operativă şi previzională a
structurilor organizatorice, a perfecŃionării metodelor şi proceselor informaŃionale ale
conducerii în vederea asigurării eficienŃei economice maxime şi a rentabilizării unităŃii
economice beneficiare. Ele sunt diferenŃiate în funcŃie de nivelele unităŃii micro, meso şi
macroeconomice şi au caracteristici generale şi specifice, subordonate cadrului legislativ, a
dotării cu tehnică de calcul şi a cerinŃelor dezvoltării economice imediate şi de perspectivă a
unităŃii beneficiare.
Aceste obiective se pot detalia astfel:
• obiective de conducere
• obiective informaŃionale
• obiective tehnologice
• obiective informatice
Obiectivele de conducere vizează probleme cu caracter global şi structural cu scopul
realizării funcŃiilor unităŃii economice şi a atributelor conducerii.
Conducerea are în vedere probleme globale ce trebuie să atingă următoarele
deziderate:
• realizarea în condiŃii de eficienŃă maximă a sarcinilor pentru întreaga activitate
• realizarea globală şi structurală a indicatorilor economico-financiară
• perfecŃionarea structurilor şi activităŃilor de producŃie cu scopul asigurării unui
optim global
Problemele cu caracter structural ale conducerii au în vedere deziderate ca [21]:
• utilizarea raŃională a capacităŃilor de producŃie
• îmbunătăŃirea calităŃii producŃiei
• utilizarea raŃională a depozitelor pentru materiale şi produse finite
• utilizarea raŃională şi eficientă a salariaŃilor
• reducerea cheltuielilor de producŃie şi desfacere
• încadrarea în normele de consum a materialelor
• adaptarea activităŃii de organizare la cerinŃele concrete (operativitate şi
reducerea stocurilor)
• creşterea gradului de utilizare a capacităŃilor de producŃie existente
• diminuarea imobilizărilor de valori materiale
• creşterea vitezei de rotaŃie a mijloacelor circulante
• reducerea cheltuielilor cu caracter administrativ şi de birou
• realizarea lucrărilor de investiŃii în mod ritmic şi de calitate
• asimilarea de noi produse şi perfecŃionarea tehnologiilor de fabricaŃie
• asigurarea condiŃiilor tehnice de modernizare a utilajelor şi a altor factori de
producŃie
• introducerea automatizării şi robotizării producŃiei
• realizarea de colaborări şi specializări operative ale producŃiei
• participarea eficientă a unităŃii la divizarea internaŃională a muncii, prin
domeniul financiar-valutar
Obiectivele informaŃionale au ca scop prelucrarea automată a datelor în condiŃii de
eficienŃă economică, optimizarea fluxurilor şi circuitelor informaŃionale, furnizarea automată
a informaŃiilor cu caracter sintetic şi analitic destinate factorilor de decizie.
Acestea au în vedere probleme cu caracter strategic şi operativ.
138
Stabilirea obiectivelor sistemului informatic
Problemele cu caracter strategic au ca scop îmbunătăŃirea activităŃii şi creşterea

eficienŃei economice prin ameliorarea procesului de informare şi conducere, pe baza unei
informaŃii oportune, precise şi operative, deziderate ce se pot realiza prin [44]:
• fundamentarea deciziilor de conducere tactică, strategică şi operativă pe baza
informaŃiilor obŃinute în urma prelucrărilor sistemului informatic
• asigurarea unei coordonări a sistemului informaŃional decizional
• furnizarea selectivă a informaŃiilor de concepŃie pentru asigurarea unei
conduceri eficiente
• furnizarea automată a deciziilor de rutină în vederea degrevării conducerii de
aceste decizii
• furnizarea adecvată şi eficientă a informaŃiilor necesare factorilor de decizie ai
unităŃii, sub formă de tabele sinoptice, grafice, histograme sau diagrame de
structură prin intermediul terminalelor (monitoarelor)
Problemele cu caracter operativ au în vedere perfecŃionarea continuă a calităŃii
sistemului informaŃional ce se poate realiza prin:
• fundamentarea informaŃională operativă şi completă a proceselor decizionale
pe toate nivelele ierarhice
• creşterea calităŃii procesului decizional
• perfecŃionarea structurilor organizatorice, de conducere şi reducerea ponderii
personalului administrativ
• extinderea principiului conducerii prin excepŃie şi pe bază de obiective
• asigurarea caracterului unitar şi compatibil al sistemelor de codificare
• îmbunătăŃirea utilizării extensive şi intensive a calculatorului, inclusiv
suporturile tehnice de date
• creşterea vitezei de circulaŃie a informaŃiilor, reducerea ciclului informaŃional
şi a timpului de răspuns
Obiectivele tehnologice au ca scop asigurarea unui control centralizat şi operativ al
conducerii proceselor tehnologice prin automatizarea şi robotizarea într-un cadru informatic
realizat prin funcŃionalitatea sistemului proiectat.
Obiectivele informatice presupun utilizarea eficientă şi extensivă a calculatorului,
pregătirea şi introducerea datelor şi a reŃelei de teletransmisie a sistemului proiectat. Ele
trebuie să asigure funcŃionarea performantă, în condiŃii de fiabilitate şi stabilitate în timp, a
întregului sistem de calcul în vederea realizării funcŃionalităŃii sistemului informatic proiectat
şi se realizează prin [21] [44]:
• folosirea în reŃea a întregii game de echipamente de calcul astfel încât să
satisfacă cât mai bine cerinŃele sistemului informatic proiectat
• utilizarea cât mai eficient a memoriei calculatorului prin alocări dinamice a
spaŃiului de memorie în scopul satisfacerii permanente a tuturor utilizatorilor
sistemului informatic
• alocarea virtuală a suporturilor externe de memorie în scopul realizării unei
confidenŃialităŃi adecvate şi a unei utilizări eficiente a acestora
• realizarea celei mai adecvate şi operative metode de introducere a datelor, cu
scopul minimalizării timpului de încărcare a bazei de date
• adaptarea de soluŃii performante în realizarea procedurilor de exploatare a
bazelor de date pentru obŃinerea la termen a tuturor situaŃiilor de ieşire în care
se concretizează obiectivele noului sistem
O sinteză a acestora în figura următoare:
139
Obiectivele sistemului informatic
Generale Specifice
de conducere funcŃionale activităŃii activităŃii

(manageriale) de bază auxiliare
Activitatea Activitatea Activitatea

comercială financiar-contabilă de personal
Subactivitatea de Subactivitatea Subactivitatea Subactivitatea Subactivitatea Subactivitatea de

aprovizionare de desfacere de marketing de evidenŃă a de salarizare perfecŃionare
technico-materială personalului a calificării
personalului
Subactivitatea Subactivitatea Subactivitatea de

financiară de control financiar
contabilitate:
- financiară
Figura 4.13 Obiectivele sistemului informatic [27]

Obiectivele sistemului informatic se vor concretiza în situaŃia de ieşire definite în
proiectarea generală şi cuantificabile în urma implementării şi exploatării curente a sistemului
informatic de unitatea economică beneficiară.
4.7. ImportanŃa modelării datelor

Modelul conceptul al datelor este o modalitate de reprezentare a datelor beneficiarului,
iar scopul său este de a reliefa toate regulile privind identitatea şi legăturile existente între ele.
Forma cunoscută de utilizare a modelării datelor este diagrama entitate-relaŃie (DER), care
este aproape identică cu cea folosită în analiza şi proiectarea orientată pe obiect. Modelarea
prin DER arată caracteristicile şi structura datelor independent de modul în care acestea sunt
memorate de calculator, acest model fiind iterativ. În urma descrierii complete a intrări şi
ieşiri sistemului, în cadrul proiectării logice, acest model de date este redat sub forma entitate-
relaŃie şi este rafinat înainte de a fi trecut într-un format logic, de unde se definesc bazele de
date şi se proiectează fizic acestea. Pe parcursul modelării datelor se produc şi se analizează
cel puŃin patru diagrame entitate-relaŃie:
• DER care să acopere doar datele necesare aplicaŃiei proiectului
• DER pentru aplicaŃia ce va fi înlocuită
140
ImportanŃa modelării datelor
• DER ce să scoată în relief întreaga bază de date din care noua aplicaŃie îşi va
extrage datele
• DER pentru întreaga bază de date din care aplicaŃia curentă îşi extrage datele
necesare
4.7.1. Conceptul diagramă entitate-relaŃie

Este unul din conceptele esenŃiale ale analizei şi proiectării structurate. Scopul acesteia
este de a evidenŃia entităŃile de date (obiectele ce solicită păstrarea datelor) şi relaŃiile
existente între acestea.
DiferenŃa dintre DFD şi DER, este aceea că DFD -ul arată atât procesele de prelucrare
cât şi entităŃile de date, iar DER -ul tratează doar entităŃile de date.
Deci, DER -ul poate fi considerată ca diagrama modelului datelor sau digrama
conceptuală a datelor.
Crearea unei DER necesită găsirea răspunsului la întrebarea: Care sunt entităŃile
despre care sunt necesare datele stocate? Răspunsul fiind simplu: aria de extindere a
sistemului analizat.
La descrierea DER se apelează la simbolul dreptunghi pentru entităŃi. În urma
identificării entităŃilor se trece la împerecherea lor, ca să descrie relaŃiile dintre ele cu ajutorul
săgeŃilor.
În lucrul cu DER, o mare importanŃă o deŃine cunoaşterea faptului că întotdeauna
relaŃiile multe-la-multe pot fi descompuse în două relaŃii de tipul unu-la-multe, prin aflarea
entităŃii-intersecŃie.
Entitatea intersecŃie este ceva ce se impune de la sine între cele două entităŃi, putându-
se marca momentul de căutare a noii entităŃi, spre exemplu:
PRODUS ? VÂNZARE
Semnul ? înlocuieşte răspunsul pe care trebuie să-l găsim la întrebările: Care poate fi
asociat cu entitatea generală simplă PRODUS ce să poată da naştere la o legătură de tip
multe?, etc..
Analiza entitate-relaŃie este o operaŃie deosebit de importantă pentru a scoate în relief
datele şi structurile lor.
EntităŃile sunt obiecte sau evenimente, fenomene sau procese economice. Obiectele se
caracterizează printr-o esenŃă de-a lungul timpului, iar evenimentele îşi fac simŃită prezenŃa la
un moment dat. EntităŃile conŃin în structura lor atribute prin care sunt descrise.
Entitatea este o persoană, un loc, un obiect, eveniment sau concept din domeniul de
activitate al beneficiarului despre care firma doreşte să păstreze anumite date.
Trebuie precizată diferenŃa dintre tipurile entităŃilor şi cazurile / instanŃele entităŃii.
Tipul entităŃii sau clasa entităŃii este o colecŃie de entităŃi ce au proprietăŃi sau
caracteristici comune. Tipului de entitate i se atribuie un nume conform descrierilor.
InstanŃa sau instanŃierea unei entităŃi sau caz al entităŃii, este o manifestare singulară a
unui tip de entitate.
Tipul de entitate se descrie o singură dată prin modelul datelor, în timp ce cazurile
acelui tip de entitate pot fi reprezentate prin datele stocate în baza de date.
Atributul este o proprietate sau caracteristic unei entităŃi ce prezintă interes pentru
firmă. La fel ca tipurile de entităŃi, numele de atribute se scriu cu litere mari şi sunt plasate în
interiorul unor elipse şi sunt legate cu entitatea căreia îi sunt ataşate, spre exemplu:
141
NUME SALAR PROFESIE
ANGAJAT
MARCĂ ADRESA
Fiecare entitate trebuie să aibă un atribut sau set de atribute prin care se efectuează
diferenŃierea unui caz de acelaşi tip, care se va sublinia.
RelaŃia este o asociere între cazurile / instanŃele uneia sau mai multor tipuri de entităŃi
ce prezintă interes pentru firmă. Aceasta este simbolizată de regulă printr-un romb ( ). În
general relaŃiile sunt redate prin verbe. În continuare prezentăm simbolurile folosite la
diagrama entitate relaŃie.
4.7.1.1. NotaŃia CHAN

P. P. Chan este considerat creatorul modelului diagramă entitate-relaŃie (DER).
Acordând o importanŃă deosebită relaŃiei care se stabileşte între două entităŃi, cu utilizarea
simbolului romb pentru redarea acesteia, iar pentru redactarea tipului de legătură apelează la
caracterele: 1, M, N, plasate chiar pe linia de legătură dintre entităŃi şi relaŃie sau dintre relaŃie
şi entitate, fără vârfuri de săgeŃi. Spre exemplu [22]:
1 1
ŞEF Conduce BIROU
1 M
VÂNZARE Desfacere PRODUS VÂNDUT
M N
FURNIZOR Livrează PRODUS
4.7.1.2. NotaŃia ROSS

Ross foloseşte simbolul romb pentru a prezenta relaŃia sau asocierile, dar caracterele 1,
M, N, nu sunt folosite la redarea tipului lor, apelându-se la vârful cu săgeată unic (pentru 1)
sau dublu pentru M. Ross recunoaşte ca tipuri: entităŃile de fond (de bază) şi entităŃile
dependente, ce nu există fără o entitate fond. La diferenŃiere, Ross utilizează notaŃia specială
în colŃul stânga sus al entităŃii-caracteristică, o casetă mică unde se plasează litera c . Spre
exemplu [22]:
ŞEF Conduce BIROU

1:1
FURNIZOR Livrează PRODUS

M: N
VÂNZARE Desfacere PRODUS VÂNDUT

1: M
C
ANGAJARE STUDII ÎN LUCRU
142
ImportanŃa modelării datelor
4.7.1.3. NotaŃia LBMS

CombinaŃia de litere vine de la furnizorul produsului CASE AUTOMATE-PLUS, care
este: Learmonth and Burchett Management Systems (LBMS). Produsul foloseşte doar relaŃia
de tipul unu la unu şi unu la mulŃi în construcŃia DER. Pe acestea le numeşte Logical Data
Structures (LDSs), deci structuri logice de date. În acest caz relaŃia mulŃi la mulŃi se
descompune în relaŃia unul la mulŃi prin apelarea la entitatea intersecŃie. Spre exemplu [22]:
PRODUS FURNIZOR
SURSĂ PRODUS
Se folosesc notaŃiile:
• linia simplă fără săgeată este 1 (unu)
• linia finalizată cu săgeată arată M (mulŃi)
• relaŃia opŃională este marcată cu un cerc plasat la mijlocul liniei ce uneşte
entităŃile, astfel:
4.7.1.4. Diagramele istoricul-vieŃii-entităŃii

Realizatorii produsului LBMS au lansat un alt element, digrama istoricul-vieŃii-
entităŃii, oferind tot grafic logica detaliată a operaŃiilor ce contribuie la actualizarea bazelor de
date. Se folosesc următoarele patru simboluri:
- entitate; - înserare eveniment;
- modificare eveniment; - ştergere eveniment.
• - într-un simbol arată repetiŃie, care poate fi pentru simbol sau pentru un grup
de simboluri. Spre exemplu: ciclul de viaŃă a unui calculator:
CALCULATOR
Cumpărare
Sesiune de lucru *
ReparaŃii ÎntreŃinere
Casare
4.7.1.5. Matricele şi analizele de afinitate

În informatică anumite aspecte pot fi reprezentate cu matrice, arătând care dintre
membrii unui set de entităŃi sau factori se află în legătură cu membrii altui set. Procesele se
află în interacŃiune cu locurile de stocarea datelor pentru generarea de noi înregistrări,
actualizarea sau citire lor.
143
Aceste legături se pot reda matricial pentru orice problemă economică. Dacă o
aplicaŃie utilizează mai multe ecrane, cu proiectanŃi diferiŃi, este necesară realizarea unei
matrice care să prezinte datele elementare ce apar în acele ecrane. Ecranele similare se pot
depista cu uşurinŃă dacă numărul lor este mic şi datele elementare sunt puŃine.
Probleme sunt atunci când numărul ecranelor şi al datelor este de ordinul sutelor, în
acest caz doar calculatorul poate face analize minuŃioase.
Produsul CASE, are utilitarul EXCELERATOR, numit Proiect de ecrane/rapoarte
echivalente, prin care se listează ecranele şi rapoartele ce folosesc exact aceleaşi date
elementare.
Există şi posibilitatea obŃinerii unui raport al Proiectelor de subseturi de
ecrane/rapoarte, care pot afla locurile în care anumite elemente utilizate sunt subseturi ale
elementelor utilizate de altele.
4.8. Proiectarea situaŃiilor de ieşire ale sistemului informatic

Practic obiectivele sistemului informatic se concretizează în satisfacerea cerinŃelor
informaŃionale ale factorilor de decizie ai unităŃii economice beneficiare.
Aceste cerinŃe sunt reflectate prin intermediul indicatorilor economico-financiar ce
sunt grupaŃi în diferite situaŃii de ieşire, ce asigură materializarea obiectivelor propuse.
Aceste situaŃii ce se proiectează vor fi IEŞIRILE sistemului informatic şi cad sub
incidenŃa actelor normative ce determină conŃinutul lor economic.
SituaŃiile de ieşire trebuie să reflecte în conŃinutul lor, stare şi dinamica fenomenelor şi
proceselor economice ce fac obiectul prelucrării datelor din sistemul informatic proiectat, iar
natura prelucrărilor are caracter specific ce depinde de natura activităŃii desfăşurate. Stabilirea
concretă a conŃinutului, formei şi a circulaŃiei documentelor (situaŃii) de ieşire sunt realizate în
funcŃie de obiectivele propuse, actele normative în vigoare şi de cerinŃele specifice
beneficiare. RestricŃiile impun un anumit conŃinut economic al situaŃiilor inclusiv elemente
referitoare la destinaŃie, utilizare, frecvenŃa şi forma în care mai apare.
Unitatea economică beneficiară împreună cu colectivul de proiectare stabilesc
conŃinutul şi forma situaŃiilor de ieşire ale sistemului informatic preconizat. La stabilirea
conŃinutului şi formei situaŃiilor de ieşire, unitatea beneficiară îşi exprimă opŃiunile dorite, iar
proiectantul verifică măsura în care posibilităŃile tehnice permit obŃinerea lor în funcŃie de
performanŃele şi limitele sistemelor electronice de calcul şi gestiune a datelor.
Fiecărei situaŃii de ieşire i se stabilesc în detaliu informaŃiile sau indicatorii pe care
trebuie săi conŃină, modul de ordonare a informaŃiilor în situaŃie, criteriile de subtotal şi
total, algoritmi de calcul ai indicatorilor pe orizontală şi verticală. Se mai precizează
suportul tehnic de obŃinere, Ńinându-se cont de restricŃiile tehnice ale imprimantei de tip
economic sau monitorului (terminal), cu menŃiunea că la imprimantă un rând poate avea 132
caractere şi pagina poate conŃine 50-70 linii, în timp ce monitorul poate avea 80 caractere pe
linie şi maximum 24 linii pe un ecran.
La stabilirea situaŃiilor de ieşire, trebuie avute în vedere elemente ca [21]:
• titlul situaŃiilor ce va reda sintetic conŃinutul informaŃional al acesteia şi
perioada sa de referinŃă
• indicatorii prezenŃi în fiecare coloană, modul de ordonare şi grupare a acestora
• natura şi lungimea maximă a fiecărui indicator
• precizarea gradelor de subtotal şi total
• cheia de determinare şi de control a indicatorilor
• volumul estimărilor exprimat prin numărul de linii într-o anumită perioadă de
timp (zi, lună, trimestru, etc…)
144
Proiectarea bazei informaŃionale a noului sistem.
• număr de exemplare, destinaŃia lor, frecvenŃa şi termenele de obŃinere

Se mai recomandă în definirea conŃinutului şi formei acestor situaŃii de ieşire, să se
urmărească o valorificare cât mai deplină a posibilităŃilor de prelucrare oferite de calculator
prin asocierea introducerii sistemului informatic cu utilizarea principiilor conducerii prin
excepŃie, precum şi utilizarea deciziilor programate, pentru degrevarea personalului de
conducere de activitatea de rutină.
SituaŃiile de ieşire trebuie să aibă o formă simplă, inteligibilă, precum şi un grad cât
mai ridicat de vizibilitate şi facilitate în utilizare, ceea ce impune emiterea detaliilor
nesemnificative, ce nu corespund scopului propus.
4.9. Proiectarea bazei informaŃionale a noului sistem.

Pentru realizarea unui sistem informatic trebuie să fie determinată baza
informaŃională. Ea trebuie să satisfacă multitudinea obiectivelor solicitate de beneficiar prin
intermediul situaŃiilor de ieşire. Deci baza informaŃională va conŃine un nucleu informaŃional
constituit din mulŃimea atributelor necesare şi suficiente asigurării prelucrărilor specifice
sistemului informatic şi structura informaŃională sub forma unui ansamblu omogen de entităŃi
între care se pot stabili o multitudine de corespondenŃe sau legături.
Baza informaŃională se proiectează în două faze:
• stabilirea conŃinutului bazei informaŃionale şi a algoritmilor utilizaŃi
• stabilirea structurii bazei informaŃionale
4.9.1. Stabilirea conŃinutului bazei informaŃionale

Determinarea conŃinutului bazei informaŃionale se face în funcŃie de variantele: ieşiri-
intrări, intrări-ieşiri, sau mixtă care se vor aplica în raport de complexitatea sistemului
informatic.
Varianta de abordare ieşiri-intrări asigură stabilirea conŃinutului bazei informaŃionale
ale noului sistem în funcŃie de obiectivele propuse, concretizate în situaŃiile de ieşire impuse
de unitatea beneficiară. Deci pe baza ieşirilor solicitate de beneficiar se stabileşte conŃinutul
adecvat al bazei informaŃionale ce va cuprinde atributele de intrare concretizate sub forma
unui nucleu informaŃional, care limitează conŃinutul şi dimensiunea bazei informaŃionale.
Baza informaŃională astfel constituită se poate modifica pe parcursul exploatării
noului sistem ca urmare a dinamicii fenomenelor şi proceselor economice din unitatea
beneficiară.
Varianta prezintă avantajul că asigură determinarea conŃinutului bazei informaŃionale
în concordanŃă cu natura ieşirilor preconizate şi dezavantajul că acest conŃinut este lipsit de
flexibilitate. Dacă se solicită schimbarea conŃinutului şi setul de ieşiri informaŃionale de către
unitatea beneficiară se impune o reconsiderare a conŃinutului bazei informaŃionale. Varianta
este recomandabilă în cazul sistemelor informatice mari şi mijlocii caracterizate printr-o
complexitate ridicată a ieşirilor informaŃionale şi implicit a obiectivelor avute în vedere.
Varianta de abordare intrări-ieşiri permite stabilirea conŃinutului maxim al bazei
informaŃionale prin surprinderea atributelor primare existente în sfera de acŃiune a noului
sistem inclusiv legăturile naturale ce urmează să facă parte din nucleul informaŃional.
Varianta prezintă avantajul flexibilităŃii conŃinutului bazei informaŃionale dacă se
solicită modificări ale ieşirilor informaŃiilor, dar are dezavantajul că supradimensionarea baza
informaŃională, ceea ce implică timp mare de realizare, costuri ridicate de proiectare şi o
sporire a complexităŃii prelucrărilor sistemului informatic. Aceasta este utilizabilă în
145
condiŃiile realizării unui sistem informatic mic, ce poate fi caracterizat prin dinamismul
ieşirilor solicitate în funcŃie de varietatea obiectivelor.
Stabilirea conŃinutului bazei informaŃionale prin varianta ieşiri-intrări necesită
studierea mulŃimii atributelor din situaŃiile de ieşire în funcŃie de modul obŃinerii lor la
calculator şi structurarea lor în două submulŃimi:
• submulŃimea atributelor de ieşire – ce se obŃin prin simpla preluare sau
reducere a unor atribute sinonime din conŃinutul bazei informaŃionale. De
exemplu: “SituaŃia valorii materiale intrate”, informaŃiile: cod furnizor, număr
factură, cont corespondent şi preŃ unitar sunt atribute de ieşire obŃinute prin
simpla preluare a lor din conŃinutul bazei informaŃionale;
• submulŃimea atributelor de ieşire obŃinute ca rezultat al utilizării unui
algoritm sau grup de algoritmi – Ea se va descompune în continuare cu
ajutorul algoritmului în operanzi primari. Operandul primar fiind un atribut
ce nu se mai poate descompune în alte atribute.
Exemplu: aceeaşi situaŃie ca la submulŃimea precedentă, valoarea se determină
prin algoritmul:
Valoarep = preŃ livrarep * cantitatep, iar valoarea totală a facturii se determină
n
prin algoritmul: Valoare totală f = ∑Val
p =1
p
Dacă atributul de ieşire ce sa analizat rezultă dintr-un calcul, se identifică algoritmul

sau algoritmii utilizaŃi, inclusiv operanzii primari, ce vor fi incluşi în conŃinutul bazei
informaŃionale, în cazul încă ei nu au fost deja introduşi.
Aplicarea variantei presupune determinarea corectă a algoritmului şi a operanzilor
primari corespunzători. Sunt situaŃii în care algoritmul se reduce la o simplă operaŃie de calcul
(exemplu: valoare = preŃ * cantitate) şi în alte cazuri algoritmul poate fi complex şi este
compus dintr-o succesiune de operaŃii, ce generează rezultate intermediare.
Prin figura (4.14) de mai jos se redă un algoritm de obŃinere a soldului valorilor
materiale dintr-o gestiune.
Figura 4.14. ne arată operanzii primari (elementari) ai algoritmului şi ei sunt: codul
gestiunii şi al materialului, preŃul, arhiva de stoc, stocul iniŃial, cantitate intrată şi ieşită zilnic.
Dacă determinarea atributelor de ieşire depinde şi de îndeplinirea unor condiŃii,
algoritmul se prezintă sub forma unui tabel de valori sau a unei tabele de decizii. Deci
conŃinutul bazei informaŃionale (I) se compune din submulŃimea atributelor preluate (Ap)
reunită cu submulŃimea operanzilor primari (Op), după cum rezultă din figura 4.12.
SOLD GESTIUNE
GESTIUNE SOLD MATERIAL
MATERIAL STOC PREł
ARHIVA STOC STOC INITIAL + TOTAL CANT. - TOTAL CANT.

INTRARI IESIRI
Σ CANT I. Σ CANT E.
Figura 4.14. ObŃinerea soldului [18]
146
E1 Ap
E2 Op
I Ae
Ei Ac
Algoritmi
Unde: Ae – atribute de ieşire, Ac – atribute calculate, Ei - entităŃile bazei, Ap-atribute primare

Figura 4.15 Modul de determinare al conŃinutului bazei informaŃionale
Prin urmare conŃinutul informaŃiilor astfel constituit va cuprinde totalitatea atributelor

privite ca un nucleu informaŃional, necesar şi suficient realizării obiectivelor noului sistem
informatic.
CondiŃiile pentru proiectarea corectă a conŃinutului bazei informaŃionale sunt:
• atributele de ieşire (E sau Ae) sunt formate din submulŃimea atributelor
preluate (Ap) reunită cu submulŃimea atributelor calculate (Ac), deci
E = Ap ∪ Ac , motiv pentru care cele două submulŃimi intersectate ne dă
mulŃimea vidă, deci Ap ∩ Ac = φ , rezultând că cele două mulŃimi nu au
atribute comune.
• operatori primari (Op) intersectaŃi cu submulŃimea atributelor preluate (Ap)
corespunde atributelor comune ce se regăsesc în ambele submulŃimi, fiind
diferită de mulŃimea vidă, deci, ea fiind reflectată în figura 3.12 prin porŃiunea
suprapusă.
• atributele de intrare (I) reprezintă nucleul informaŃional ce constituie
conŃinutul bazei informaŃionale, dacă se verifică simultan condiŃiile de
eficienŃă a conŃinutului acestora, prin următoarele relaŃii:
I = Op ∪ Ap; E = Ap ∪ Ac şi I ≤ E.
ConŃinutul bazei informaŃionale este dependent de acurateŃea algoritmilor folosiŃi în
concordanŃă cu cerinŃele cadrului legislativ şi în funcŃie de specificul activităŃii economice
beneficiare.
4.9.2. Algoritmi utilizaŃi de bazele informaŃionale

Modelarea logicii proceselor se va derula cât mai detaliat şi complet posibil, dar operaŃiunea
nu respectă structura sau sintaxa unui limbaj, lucru ce se realizează în altă etapă de proiectare.
Aceasta fiind o parte a subetapei de structurare a cerinŃelor sistemului.
Prin folosirea riguroasă a algoritmilor se asigură o reducere sub formă concisă,
completă şi precisă a procentului de prelucrare a atributelor inclusiv a calculelor aritmetice şi
logice, atât cele intermediare cât şi cele finale.
În cadrul proiectării sistemelor informatice se pot folosi tipuri variate de algoritmi şi
modele a logicii proceselor, cum ar fi [19]:
• reprezentarea în engleza structurată a logicii proceselor
• expresii aritmetice sau algebrice
• tabele de valori
• reprezentarea logicii proceselor cu tabele de decizie
• tabele de acŃiuni condiŃionate
• reprezentarea logicii proceselor cu arbori de decizie
147
• modelarea logicii temporale cu diagrame şi tabele ale stărilor de tranziŃie

• organigrame
Stabilirea conŃinutului bazei informaŃionale şi a algoritmilor determină condiŃiile
necesare pentru constituirea entităŃilor prin intermediul structurii bazei informaŃionale şi se
realizează pe baza următorului formular, în figura 4.16.
ANALIZA DATELOR
N.I D. D. E1 E2 E3 E4 A. S. D. S1 S2 S3 S4 S5 S6
. R. N. C. E. D
Unde: N. I. – nucleu informaŃional sau date de intrare;

D. R. - date repetitive; D. N. – date nerepetitive;
E1, E2, E3, E4, - entităŃile componente ale bazei informaŃionale;
A.C. – algoritmi de calcul, simbolul acestora;
S.E. – simbol date ieşire; D.D. – denumirea datelor de ieşire;
S1, S2, S3, S4, S4, S5, S6 – situaŃiile de ieşire ale sistemului.
Figura 4.16 Analiza datelor
4.9.3. Stabilirea structurii bazei informaŃionale

Structura bazei informaŃionale este ansamblul entităŃilor în care sunt organizate
atributele , nucleul informaŃional precum şi corespondenŃele existente între entităŃi. Aceasta
este evidentă prin intermediul unui model ce asigură dezideratul independenŃei logice şi fizice
a prelucrărilor faŃă de structura fizică în care va fi transpusă baza informaŃională şi deci
implicit independenŃa relativă a proiectării generale faŃă de soluŃiile tehnice adaptate în
proiectarea de detaliu.
Modelarea atributelor bazei informaŃionale cu scopul transpunerii acesteia în structura
sa, va fi realizată prin intermediul modelului ENTITATE-ATRIBUT-CORESPONDENłĂ
(ECA). Prin el, baza informaŃională ce urmează a se constitui, este un ansamblu finit de
entităŃi informaŃionale caracterizate în mod unic de o mulŃime de atribute şi un ansamblu de
corespondenŃe (legături) stabilite între entităŃi. Deci, corespondenŃele pot fi definite ca
asocieri între realizările aceleaşi entităŃi sau realizările entităŃilor diferite, ce pot fi de
următoarele tipuri:
• 1÷1 - corespondenŃe unice
• 1÷n - corespondenŃe multiple
• m÷n - corespondenŃe complexe
Entitatea este unitatea informaŃională ireductibilă din structura bazei informaŃionale
cu un caracter general sau specific şi cu o existenŃa determinată prin atributele sale definitorii.
Ea este caracterizată printr-o mulŃime de atribute preluate din nucleul informaŃional în
funcŃie de aplicarea unor criterii de determinare. Astfel conŃinutul bazei informaŃionale (I)
este considerat ca o colecŃie unică de atribute ce poate fi structurată într-o mulŃime de entităŃi
(ei) astfel încât I={ {ei} i ∈N} şi fiecare entitate este compusă dintr-o mulŃime de atribute (aij)
ce au următoarea structură: I = {{ai,j} i,j ∈N}.
Deci entitatea este definită printr-un nume unic (identificator), un număr maxim de
realizări (apariŃii) şi un grup de atribute de natură constantă sau variabilă care reflectă starea
sau dinamica fenomenelor şi proceselor economice având şi o mulŃime de corespondenŃe
(legături) cu alte entităŃi ce determină asocieri de tipul: 1÷1; 1÷n; m÷n.
Din punct de vedere structural entitatea poate să fie elementară şi compusă.
148
Cea elementară constituie veriga informaŃională ireductibilă a structurii bazei

informaŃionale, deci ea nu se mai poate descompune în alte entităŃi.
Cea compusă formează veriga informaŃională reductibilă a structurii bazei
informaŃionale şi este formată din două sau mai multe entităŃi elementare în vederea
optimizării structurii bazei informaŃionale. EntităŃile de acest tip se folosesc în cazul apariŃiei
corespondenŃelor de tipul m÷n ce se descompune în două corespondenŃe de tipul 1÷m şi 1÷n
prin interpunerea unei entităŃi compuse între două entităŃi elementare.
Entitatea compusă este alcătuită în principiu din trei părŃi:
• partea formată din atributele de identitate ale entităŃii compuse (exemplu:
număr comandă, dată comandă);
• partea formată din atribute de descrierea entităŃii compuse (exemplu: produs
comandat, număr contracte, dată contract);
• partea formată din atributele de legătură ce vor defini corespondenŃele dintre
entitatea compusă şi entităŃile elementare (exemplu: cod beneficiar, cod
produs).
Atributele sunt reflectate printr-un conŃinut concret denumit valoare, ce prezintă
nivelul real al fenomenelor şi proceselor economice cuantificabile prin intermediul entităŃii.
Ele pot fi privite din punct de vedere structural putând fi elementare şi compuse.
Atributele elementare reprezintă componente informaŃionale ireductibile, deci nu se
mai pot descompune în alte atribute (exemplu: cod-produs, denumire-produs, UM, preŃ de
producŃie, preŃ de livrare, etc.).
Atributele compuse reprezintă componente informaŃionale reductibile, deci ele se pot
descompune în atribute elementare (exemplu: Data stoc se împarte în: zi-stoc, lună-stoc, an-
stoc).
Privite din punct de vedere a stabilităŃii atributele se pot împărŃi în: constante,
variabile şi de stare.
Atributele constante îşi menŃin valoarea neschimbată pe toată durata existenŃei bazei
informaŃionale şi deci sunt invariabile în timp (exemplu: cod-produs, număr-contract, cod-
beneficiar, etc.).
Atributele variabile îşi schimbă valoarea pe parcursul existenŃei bazei informaŃionale,
ele fiind variabile în timp (exemplu: număr-document, data-document, cantitate intrată,
cantitate ieşită, etc.).
Atributele de stare îşi schimbă valoarea numai la anumite intervale de timp ale
execuŃiei bazei informaŃionale prin modificarea efectuată de atribute constante, variabile sau
chiar de stare (exemplu: stoc iniŃial, stoc normat, stoc de siguranŃă, stoc final, stoc final, sold
iniŃial, sold final, etc.).
CorespondenŃa este o legătură dintre două sau mai multe entităŃi în vederea reflectării
asociaŃiilor ce pot fi stabilite între entităŃi. CorespondenŃele se determină în funcŃie de natura
logică a entităŃilor şi de asociaŃiile logice ce există în sens static şi dinamic, ca urmare a
desfăşurării fenomenelor şi proceselor economice ce sunt reflectate prin intermediul structurii
bazei informaŃionale.
CorespondenŃele stabilite în cadrul bazei informaŃionale pot fi existente între entităŃi
ce aparŃin unor clase diferite cum ar fi dintre entităŃile “BENEFICIAR” şi “CONTRACTE”.
Stabilirea corespondenŃelor specifice entităŃilor bazei informaŃionale se realizează în
raport de funcŃionalitatea tipului de corespondenŃă (1÷1, 1÷n, m÷n) care implică legăturile
dintre două entităŃi diferite.
Pentru evidenŃierea corespondenŃelor dintre două entităŃi diferite ale bazei
informaŃionale prima entitate este considerată domeniu, iar a doua codomeniu.
149
CorespondenŃa de tipul 1÷1, este aceea în care unui element din domeniu îi
corespunde un sigur element în codomeniu, cu menŃiunea că pot exista elemente din domeniu
ce au corespondenŃă un codomeniu.
CorespondenŃa de tipul 1÷n este aceea în care unui element din domeniu îi corespunde
0,1 sau mai multe elemente (maxim n) din codomeniu, iar unui element din codomeniu îi
corespunde 0 sau 1 element din domeniu.
CorespondenŃa de tipul m÷n este aceea în care unui element din domeniu îi
corespunde 0,1 sau mai multe elemente din codomeniu (maxim n), iar unui element din
codomeniu îi corespunde 0,1 sau mai multe elemente din domeniu (maxim m).
Pe baza modelului EAC, stabilirea structurii bazei informaŃionale se realizează prin
fazele: definirea entităŃilor bazei informaŃionale, definirea atributelor specifice entităŃilor,
stabilirea corespondenŃelor dintre entităŃi, optimizarea structurii bazei informaŃionale,
reprezentarea structurii bazei informaŃionale.
a) Definirea entităŃilor bazei informaŃionale.
Ea se realizează prin structurarea nucleului informaŃional în entităŃi şi stabilirea
atributelor de legătură dintre acestea în funcŃie de unele criterii ca:
• omogenizarea atributelor şi semantica acestora în funcŃie de natura economică
• domeniul de activitate sau subactivitate reflectat de atributele bazei
informaŃionale
• sfera de cunoaştere reflectată de atributele bazei informaŃionale
• omogenitatea nivelului de sinteză şi atributelor bazei informaŃionale
• stabilirea în timp a conŃinutului atributelor
• omogenitatea proceselor de prelucrare aplicate atributelor bazei informaŃionale
• frecvenŃa de apariŃie şi utilizare a atributelor bazei informaŃionale
• sursa de furnizarea atributelor care formează conŃinutul bazei informaŃionale
(activitate, subactivitate, comportamente funcŃionale, documente, etc…)
Practic la stabilirea structurii bazei informaŃionale criteriile menŃionate mai sus, pot fi
folosite individual sau combinate la stabilirea setului de entităŃi ce se reflectă cel mai bine în
obiectivele solicitate şi în performanŃele sistemului informatic. În urma determinării entităŃilor
se vor stabili corespondenŃele dintre ele pe baza atributelor de legătură.
b) Definirea atributelor specifice entităŃilor.
Cu ajutorul lor se stabilesc formele de exprimare într-o manieră generală, recunoscută
şi folosită în mod unitar de către administratorul bazei informaŃionale. Deci numai
administratorul bazei informaŃionale stabileşte definiŃiile descriptive specifice fiecărui atribut,
inclusiv modul direct sau indirect de utilizare în vederea asigurării unor deziderate ca:
• stabilirea unei concordanŃe depline între definiŃiile descriptive ale fiecărui
atribut şi semantica acestora în contextul fenomenelor şi proceselor economice
reflectate de baza informaŃională
• prezentarea descriptivă a atributelor astfel încât să asigure viziunea şi
realizarea ulterioară de către administratorul bazei a unui dicŃionar al
atributelor ce se va folosi în etapa proiectării de detaliu şi trebuie să surprindă
obiectiv realitatea fenomenelor şi proceselor economice
Prin proiectarea generală se stabilesc definiŃiile convenŃionale de utilizare a fiecărui
atribut (conform figurii 4.15) caracterizat prin elementele:
• identificatorul atributelor, care trebuie să fie unic şi format din maxim 30
caractere alfanumerice inclusiv caracterele “-“şi “:” cu condiŃia ca numele să
nu înceapă printr-un caracter special
• tipul atributului poate fi: numeric, alfabetic, alfanumeric sau logică, etc…
150
• lungimea atributelor ne arată mărimea sa care este exprimată printr-un număr

de caractere
• factorul de repetitivitate al unui atribut va reflecta numărul maxim sau mediu
de apariŃii a acestuia
IDENTIFICATOR ATRIBUT
TIP ATRIBUT ALFABETIC

ALFANUMERIC
DESCRIERE ATRIBUT LUNGIME ATRIBUT LOGIC

NUMERIC
MEMORIE
FACTOR DE REPETIVITATE DATĂ CALEND.
Figura 4.17 Descrierea atributelor bazei informaŃionale

În definirea acestora, rolul esenŃial revine atributelor de legătură dintre entităŃi, ce
trebuie să asigure identificarea unică a fiecărei entităŃi precum şi realizarea corespondenŃelor
statice şi dinamice dintre acestea, motiv pentru care este indicat ca aceste atribute să fie de tip
numeric şi de lungime minimă, cerinŃă ce se va asigura prin intermediul codificării.
Atributele de legătură sunt chei primare sau secundare în cazul exploatării efective ale
entităŃilor bazei informaŃionale.
c) Determinarea corespondenŃelor dintre entităŃi.
Această subfază este un mod concret de reflectare a legăturilor dintre entităŃi în scopul
asigurării unei integrări cât mai bune a acestora în cadrul structurii bazei informaŃionale.
CorespondenŃele determină flexibilitatea structurii bazei informaŃionale în cazul că acestea
sunt în mod obiectiv şi natural stabilite. Pentru realizarea acestor deziderate, administratorul
bazei de date trebuie să cuprindă toate legăturile dintre entităŃi şi să le reprezinte prin
intermediul tipului lor (1÷1; 1÷n; m÷n). Ele sunt reflectate prin intermediul atributelor de
legătură ce îndeplinesc funcŃia de cheie primară în codul fiecărei entităŃi. La asigurarea
corespondenŃei, este necesar ca acea cheie primară să aibă valori egale motiv pentru care
cheia primară dependentă poartă denumirea de cheie externă în raport cu entitatea ce este în
corespondenŃă.
Pentru explicitarea corespondenŃelor dintre entităŃi se vor folosi unele criterii:
• sfera de reflectare a activităŃilor
• natura economică a entităŃilor
• operaŃia economică reflectată de entitate
• numărul de realizări specifice entităŃilor
• succesiunea logică a activităŃilor
• cardinalitatea minimă şi maximă a entităŃilor
Sfera de reflectare a entităŃilor. Aceasta impune unele corespondenŃe dintre entităŃile
stabilite şi specificul fiecăreia dintre ele.
Natura economică a entităŃilor necesită asocierea acelor entităŃi ce pot fi intercorelate
în contextul apartenenŃelor la aceeaşi sferă informaŃională.
OperaŃia economică reflectată de entităŃi necesită precizarea acelor corespondenŃe ce
definesc operaŃii omogene da de exemplu: intrările şi ieşirile de materiale.
Numărul de realizări specifice entităŃilor asigură realizarea corespondenŃei de tipul
1÷1 în cazul că domeniu şi codomeniu au o singură realizare, de tipul 1÷n dacă domeniul are
o singură realizare iar codomeniul mai multe. Pentru entităŃile cu mai multe realizări
151
corespondenŃele sunt de tipul m÷n, deoarece în domeniu cât şi în codomeniu sunt mai multe
realizări.
Succesiunea logică a atributelor ce se defineşte prin entitate, este în funcŃie de modul
de desfăşurare a procesului de producŃie şi permite utilizarea de corespondenŃe de tipul 1÷1,
1÷n, m÷n, în scopul asigurării continuităŃii activităŃilor prin intermediul structurii bazei
informaŃionale.
Cardinalitatea minimă şi maximă a entităŃilor presupune folosirea unor componente
în concordanŃă cu numărul de utilizări posibile ale fiecărei realizări pentru fiecare tip de
entitate în cadrul unui tip de corespondenŃă. Deci cardinalitatea minimă exprimă numărul
minim de utilizări posibile ale fiecărei realizări pentru un tip de entitate în cadrul unui tip de
corespondenŃă, în timp ce cardinalitatea maximă arată numărul maxim de realizări. La
proiectarea corespondenŃelor dintre entităŃi se pot întâlni mai multe tipuri de dependenŃe,
dintre care amintim:
1. DependenŃa funcŃională simplă dintre două atribute notate x şi y, este realizată
dacă în intervalul de existenŃă al bazei o realizare a atributului x determină o singură realizare
a atributului y, proprietate reflectată prin rotaŃia E·X →E·Y, unde E este entitatea ce conŃine
atributele x şi y, exemplu:
DependenŃă
COD-PRODUS DENUMIRE-PRODUS
funcŃională simplă
Dacă cheia primară este în dependenŃă funcŃională cu mai multe atribute, ea se va

exemplifica astfel:
DENUMIRE-PRODUS
COD PRODUS UNITATE-DE-MASURĂ
PREł-UNITAR
CHEIE PRIMARĂ
(atribut independent) (atribute dependente)
2. DependenŃa funcŃională multiplă dintre două atribute notat x şi y, este realizată
dacă în intervalul existent al bazei o realizare a atributelor x determină mai multe realizări ale
atributului y, proprietate reflectată de notaŃia E·x→E·B. De exemplu:
DependenŃă
COD-SECTIE COD-ATELIER
funcŃională multiplă
(atribut independent) (atribut dependent)
Pentru dependenŃele funcŃionale simple sau multiple se pot face combinaŃii ale
acestora pentru evidenŃierea cât mai veridică a tuturor legăturilor dintre atribute. De exemplu:
DENUMIRE-ATELIER
COD-SECTIE COD-ATELIER TIP-ATELIER
MARCA
(atribut independent) (atribut dependent) (atribut dependent)
cheie de legătură cheie primară cheie finală
152
Formalizarea atributelor
3. DependenŃa funcŃională dublă sau triplă, este realizată prin intercombinarea a

două sau mai multe dependenŃe funcŃionale simple sau multiple. DependenŃa este dublă dacă
se folosesc combinări ale altor două dependenŃe simple sau multiple şi este triplă dacă se
folosesc trei tipuri de dependenŃe.
Definirea entităŃilor, atributelor, corespondenŃelor dintre entităŃi şi dependenŃele
funcŃionale dintre atribute, este premisa optimizării structurii bazei informaŃionale în scopul
sesizării şi eliminării tuturor anomaliilor ce ar putea afecta performanŃele bazei.
4.10. Formalizarea atributelor

Ea are ca scop realizarea activităŃilor de elaborare a codurilor şi de adaptarea
documentelor de intrare la cerinŃele noului sistem informatic. Aceasta se împarte în două
etape:
• codificarea atributelor
• adaptarea documentelor de intrare la cerinŃele sistemului informatic
4.10.1. Codificarea atributelor şi clasificarea lor

Ea este o etapă importantă în realizarea oricărui sistem informatic, constând în
acordarea de coduri componentelor sale structurale, elementelor ce fac obiectul prelucrării
precum şi atributele componente ale structurii bazei informaŃionale. Această activitate trebuie
să asigure o corelaŃie între particularităŃile sistemului proiectat şi specificul unităŃii
beneficiare, ce trebuie să îndeplinească cerinŃe ca:
Unicitatea codului, ce presupune existenŃa unui singur simbol pentru un element al
mulŃimii codificate, prin asigurarea de valori unice pentru un obiect codificat, cerinŃă ce
trebuie asigurată la nivelul întregului sistem informatic.
SupleŃe şi stabilitate, ce presupune că un cod odată atribuit să fie folosit o perioadă cât
mai mare de timp să se adapteze uşor extensiilor de volum ale elementelor pe care le
reprezintă.
Comoditatea utilizării, se referă la facilitatea operaŃiei de codificare-decodificare
precum şi la detectarea şi corectarea simplă a erorilor. Deci codurile trebuie să fie uşor de
înŃeles şi de aplicat atât de cei care le-au conceput cât şi de cei care le folosesc.
Concizia se referă la necesitatea folosirii unui număr cât mai mic de caractere pentru
reprezentarea elementelor codificate. Ea asigură reducerea dimensiunii înregistrărilor şi
creşterea vitezei de prelucrare, precum şi reducerea procentului de erori în procedurile de
introducere a datelor prin intermediul monitoarelor.
Pentru asigurarea cerinŃelor anterioare, codificarea atributelor constituie o operaŃie
autonomă sau normală de atribuire într-o formă sistematizată a unor coduri fiecare element
component al noului sistem informatic.
Codul este reprezentat de o mulŃime de simboluri acordate atributelor din conŃinutul
bazei.
Simbolul este reprezentat de un şir de caractere care permit exprimarea într-o formă
convenŃională a unui element din ansamblul de atribute codificate.
Simbolul este format dintr-un şir de caractere numerice, alfanumerice sau alfabetice ce
pot fi interpretate de factorul uman sau de procedurile automate ale noului sistem informatic.
Prin această viziune, codul este o colecŃie ordonată de simboluri formate la rândul lor şiruri de
caractere ce asigură identificarea şi utilizarea unei entităŃi sau a unui atribut al bazei
informaŃionale.
Prin codificare vom avea următoarele avantaje, în prelucrarea automată a datelor:
153
• înlocuirea atributelor prin coduri numerice, alfanumerice şi alfabetice, ce

permit utilizarea intensivă a suporturilor externe şi a memoriei interne
• realizarea unei ierarhizări a atributelor în funcŃie de cerinŃele specifice
prelucrării, putând obŃine o adunare a acestora în raport cu cerinŃele de
selectare a atributelor din bază sau obŃinerea totalurilor şi subtotalurilor în
situaŃiile de ieşire
• optimizarea timpului de acces la bază de date
• reducerea erorilor prin folosirea codurilor ce înlocuiesc utilizarea explicită a
valorilor atributelor
• simplificarea scrierii codurilor în comparaŃie cu utilizarea denumirilor explicite
a atributelor pentru care regulile de scriere sunt complexe şi greu de respectat
Deci structura logică a codurilor trebuie să asigure realizarea optimă a unei
corespondenŃe biunivoce între mulŃimea valorilor reale ale atributelor şi mulŃimea codurilor
asociate acestora.
Complexitatea şi diversitatea conŃinutului bazei informaŃionale precum şi multitudinea
proceselor de prelucrare a atributelor, au determinat apariŃia unei game variate de coduri.
O clasificare a acestora după unele criterii se prezintă în continuare:
A. După structura simbolurilor avem:
• coduri elementare, ce pot fi:
- coduri secvenŃiale
- coduri secvenŃiale pe grupe
- coduri cu semnificaŃie mnemonică
- coduri cu semnificaŃie descriptivă
• coduri complexe, ce pot fi:
- coduri ierarhizate, ce pot fi: - liniar
- zecimal
- coduri jucstapuse
- coduri combinate, ce pot fi: - matricială
- în bază binară
B. După modul de detectare şi corectare erorilor, acestea pot fi:
• autodetectoare de erori
• autocorectoare de erori
C. După natura atributelor, pot fi:
• numerice
• alfabetice
• alfanumerice
D. După lungime, pot fi:
• de lungime fixă
• de lungime variabilă
E. După modul de elaborare, pot fi:
• manual
• automat
În cele ce urmează se va face o prezentare succintă a acestei clasificări:
1. Codurile elementare. Acestea au rolul de a identifica un element din cadrul unei
mulŃimi de elemente. Ele sunt compuse din: coduri secvenŃiale, secvenŃiale pe grupe, cu
semnificaŃie mnemonică şi descriptivă.
a) Codurile secvenŃiale, se formează prin atribuirea unui şir de caractere fiecărui
element al mulŃimii stabilind o corespondenŃă crescătoare între elementele acestora şi
mulŃimea numerelor naturale. Deci fiecărui element supus codificării îi este asociat un cod
154
crescător imediat disponibil. Codurile secvenŃiale sunt realizate în funcŃie de caracterele unui
sistem de numeraŃie (b) şi lungimea simbolului propus (n), ceea ce asigură o lungime maximă
a codului (Lmax = bn) . Lungimea codului va include un număr maxim de elemente dependent
de valorile lui b şi n.
b) Codurile secvenŃiale pe grupe sunt formate prin rezervarea unui set maxim de
simboluri pentru fiecare tip de atribut omogen caracterizat prin particularităŃi comune ce
formează o grupă specifică supusă codificării. Aceste grupe sunt dependente de specificul
economic al atributelor şi de cerinŃele de prelucrare omogenă ale acestora, cu precizia că în
cadrul fiecărei grupe i se vor atribui coduri secvenŃiale până la valoarea maximă rezervată
acesteia.
c) Coduri cu semnificaŃie mnemonică. Acestea se formează fie din consoanele unui
cuvânt sau prin prescurtarea (abrevierea) denumirii elementului codificat şi este folosit cel
mai des în prelucrări normale.
d) Coduri cu semnificaŃie descriptivă. Ele se formează prin combinarea iniŃială
denumirii cu caracteristicile tehnico-constructive ale elementelor de codificare şi este folosit
în mod special la nomenclatoarele produselor industriale.
2. Coduri complexe. Ele conŃin atribute ce aparŃin unor mulŃimi destinate, ce se
folosesc în mod unitar. Aici sunt incluse codurile ierarhizate, juxtapuse şi combinate.
a) Coduri ierarhizate. Ele sunt utilizate atunci când există relaŃii de subordonare între
atributele mulŃimii cărora le aparŃin. De aici fac parte cele ierarhizate şi zecimal.
Cele ierarhizate simplu ne redau modul de subordonare a atributelor din mulŃimile ce
formează structura codului.
Cele ierarhizate zecimal ne redau modul de subordonare a atributelor ce sunt ordonate
pe grupe şi secvenŃial crescător în cadrul acestora.
b) Coduri juxtapuse. Ele sunt obŃinute prin concatenarea codurilor asociate unor
atribute individuale ce au o semnificaŃie distinctă în vederea utilizării grupate sau individual a
atributelor codificate.
O structură de cod juxtapus prezentăm în exemplul următor:
9 99 99 9999
Marca
Echipă
Atelier
SecŃie
Acest exemplu ne prezintă formarea corectă a unui cod de marcă pentru un salariat al
unei secŃii, dintr-un atelier al secŃiei şi făcând parte dintr-o echipă de lucru.
c) Codurile combinate. Acestea surprind structura lor relaŃiile logice existente între
diferite proprietăŃi ale atributelor cuprinse în cadrul conŃinutului bazei informaŃionale. De aici
fac parte codurile matriciale şi cele cu bază binară.
Cele matriciale sau şah se utilizează în cazul că atributele de codificat pot fi
caracterizate de două posibilităŃi ce pot fi combinate prin intermediul unui cod.
Cele cu bază binară se folosesc pentru a reflecta în mod sugestiv şi simplu prezenŃa
sau absenŃa însuşirilor ce caracterizează simultan atributele bazei informaŃionale. Aceste
însuşiri se codifică prin puterile lui 2 (ce e bază de numeraŃie a sistemului binar) şi fiecare
poate lua valorile 0 sau 1 în funcŃie de prezenŃa sau absenŃa proprietăŃii atributului respectiv.
4.10.2. Coduri şi metode de verificare a acestora

Deoarece, prin folosirea codurilor pentru atributele bazei informaŃionale pot interveni
erori de codificat cu consecinŃe imprevizibile în prelucrare, în acest scop s-au elaborat coduri
ce conŃin chei de control ce permit depistarea automată a erorilor de identificare înainte de
155
prelucrarea şi obŃinerea rezultatelor. De aici fac parte codurile autodetectoare şi

autocorectoare de erori.
1. Coduri autodetectoare de erori.
Ele se bazează pe existenŃa unei chei de contact formează din una sau două poziŃii
numerice sau alfabetice, ce se ataşează la dreapta structurii codului. Aceste chei se determină
prin metodele de calcul:
• aritmetică
• modulo 9
• geometrică
• literei de control
a. Metoda aritmetică stabileşte cheia de control (C) pe baza sumei produselor
obŃinute prin înmulŃirea fiecărei cifre a codului (Ci ) cu anumite valori convenŃional alese,
denumite ponderi (Pi ) ale codului, care de obicei sunt cifrele 1 şi 2 completate de la dreapta la
stânga de câte ori e necesar, număr ce urmează să fie scăzută din cifra zecilor imediat superior
(Z). Algoritmul este:
n
C = Z − ∑ Ci Pi
i =1
Exemplu:
6 7 8 3 4 2 8
1 2 1 3 1 2 C
6+ 14+ 8+ 6+ 4+ 4 = 42
C = 50-42 = 8
Avantajul ei constă în simplitatea şi acurateŃea acesteia, iar dezavantajul constă în
imposibilitatea sesizării erorilor de compensare.
b. Metoda modulo 9 stabileşte cheia de control (C) pe baza sumei produselor obŃinută
prin înmulŃirea fiecărei cifre a codului (Ci), cu anumite valori convenŃional alese, numite
pierderi (Pi ) ale codului, care de obicei sunt cifrele de la 1 la 9 mai puŃin 3 şi multiplii lui,
completat de la dreapta spre stânga de câte ori e necesar, sumă ce se împarte la modul (la noi
9) se obŃine un cât şi un rest (R). Algoritmul este:
n
S
S = ∑ Ci P i . ; = cit + R ; apoi se calculează cifra de control: C = 9 - R
i =1 9
Exemplu:
6 7 8 3 4 2 3
8 7 5 4 2 1 C
48+ 49+ 40+ 12+ 8+ 2 = 159

159 : 9 = 17 R = 6
C=9–6=3
c. Metoda geometrică stabileşte cheia de control (C) ca rest al împărŃirii sumei

produselor fiecărei cifre a codului cu ponderile (Pi), ce sunt puterile crescătoare ale lui 2 la un
număr prim ales convenŃional (x), după algoritmul:
n
S
S = ∑ Ci Pi , = cit + R, C = R, pi = 2i −1
i =1 X
156
De mărimea lui x depinde numărul de cifre ale cheii de control dacă este format din 2
cifre va rezulta un număr de control, iar dacă este format dintr-o cifră va rezulta cifră de
control.
Exemplu:
6 7 8 3 4 2 22
25 24 23 22 21 20 Nr. Control
192+ 112+ 64+ 12+ 8+ 2= 390

x = 23 număr prim ⇒ 390 = 23x16 + 22
Această metodă duce la lungimea mărimii codului, dar are marele avantaj că asigură
un grad ridicat de siguranŃă în prelucrarea datelor.
d. Metoda literei de control este utilizată pentru a se evita mărimea lungimii codului
şi pentru a limita posibilitatea apariŃiei erorilor de compensaŃie. Ea este o variantă a
precedentei metode şi este caracterizată prin faptul că numărul prim ales este în mod constant
23 (deoarece este cel mai mare număr prim din totalitatea literelor alfabetului englezesc), iar
litera de control se obŃine prin aplicarea algoritmului metodei geometrice şi transformării
restului împărŃirii în litera corespunzătoare a alfabetului englezesc.
Exemplu: rest = 01 se face tabelul de corespondenŃă dintre rest şi litere astfel:
Rest 00→litera A
Rest 01→litera B
Rest 02→litera C
Rest 02→litera D
...............................
Rest 22→litera W
6 7 8 3 4 2 W
25 24 23 22 21 20 literă de control
Principiul de verificare al codului va fi acelaşi indiferent de modalitatea sa de calcul.
La citirea codului calculatorul aplică algoritmul de calcul al cheii de control şi compară
rezultatul obŃinut cu cheia introdusă odată cu codul. Dacă cheia calculată este definită de cea
atribuită codului apare eroare de introducere a codului, care poate fi generată de inversarea
cifrelor codului introdus sau transcrierea eronată a codului pe documentul dat spre prelucrare.
2. Coduri autocorectoare de erori.
Ele permit pe lângă detectarea erorilor şi corectarea automată a acestora. Ca să
realizeze dezideratul propus, ele sunt aranjate sub formă matriceală, stabilind pentru fiecare
linie şi coloană câte o cheie de control determinată prin însumarea cifrelor pe linie sau pe
coloană şi scăzând rezultatul din ordinul zecilor imediat superior. Erorile ce apar se vor
localiza la intersecŃia liniei şi coloanei ale căror chei calculate sunt diferite de cheii din
valoarea absolută a erorii care trebuie corectată. Se folosesc următorii algoritmi în stabilirea
cheilor pe linie şi coloană:
m n
Clin = Z − ∑ Cj ; Ccol = ∑ Ci ; unde: i∈(1,n); j∈(1,m)
j =1 i =1
Cheia generală aferentă liniilor şi coloanelor se stabileşte cu algoritmul:

C L
CL = Z − ∑ Clinc ; CC = Z − ∑ Ccoll
c=1 l =1
Dacă CL = CC înseamnă, că cheia generală este corectă, iar dacă CL ≠ CC , se va stabili

dimensiunea erorii astfel: E = CL - CC , iar codurile fiind invalidate.
Aceste coduri ocupă spaŃiu foarte mult în memoria calculatorului, deoarece sunt
dependente de utilizarea matricelor şi de tabelele de referinŃă necesare verificării codului în
157
cele două etape şi execuŃia procedurii durează mult din cauza reluării procedurii de
identificare pentru fiecare înregistrare.
4.10.3. Codificarea bazei informaŃionale

Atributele bazei informaŃionale pot fi de tip numeric, alfabetic, alfanumeric, de
lungime fixă, sau variabilă ceea ce conduce la utilizarea unor coduri adecvate în realizarea
sistemelor informatice.
Oportunitatea activităŃii de codificare a bazei informaŃionale se poate decide în
funcŃie de următoarele criterii [7]:
• mărimea şi complexitatea conŃinutului în baza informaŃională
• tipurile de atribute existente în baza informaŃională
• complexitatea structurii sistemului informatic
• specificul operaŃiilor de prelucrare
• soluŃia celui mai eficient sistem de coduri
• costul stabilirii şi validării sistemelor de coduri
• costul decodificării atributelor din baza informaŃională
• costul elaborării, actualizării şi întreŃinerii catalogului de coduri
• efortul de adaptare a personalului din unitatea beneficiară în folosirea
sistemului de coduri
După modelul de realizare, codificarea poate fi cu sau fără pregătire prealabilă.
Cea cu pregătire prealabilă solicită analiza ansamblului atributelor de codificat care
vor precede codificare propriu-zisă şi să evalueze exact volumul atributelor, clasificările,
caracteristicile şi gama de valori posibile.
Cea fără pregătire prealabilă este realizată prin atribuirea de coduri pe măsura
apariŃiei de noi valori pentru atributele introduse în sistem. Analiza necesară în acest caz este
de a stabili volumul maxim de atribute în scopul determinării lungimii şi a limitelor codului.
În codificarea atributelor bazei informaŃionale se recomandă parcurgerea unor faze ca:
• pregătirea activităŃii de codificare
• stabilirea necesarului de codificare
• codificarea atributelor bazei
• întocmirea catalogului de coduri
• întreŃinerea codurilor
1. Pregătirea activităŃii de codificare necesită analiza conŃinutului şi structurii bazei
informaŃionale, precum şi examinarea codificărilor existente, inclusiv măsura în care acestea
satisfac cerinŃele noului sistem informatic. Aici este necesară eşalonarea în timp a codificării,
a modului de realizare şi de control, obŃinându-se pentru codificare cu sau fără pregătire
prealabilă executată manual sau automată.
2. Stabilirea necesităŃilor de codificare este dependentă de volumul atributelor
supuse codificării, timpul de cod utilizat şi de modul de realizare a acestuia. Aici se vor
parcurge unele subfaze pentru obŃinerea unei codificări corecte a bazei pe care le vom expune
în cele ce urmează.
Ordonarea atributelor bazei informaŃionale este realizată prin sortarea identificatorului
atributelor şi care presupune clasificarea atributelor pe nivele ierarhice în scopul definirii
grupelor de codificare având în vedere reguli precise de introducere a acestora în bază.
Analiza particularităŃilor conŃinutului bazei informaŃionale are ca scop evaluarea
conŃinutului actuale de codificat precum şi estimarea evoluŃiei anterioare. Acesta necesită
precizarea responsabilităŃilor pentru gestiunea bazei informaŃionale, modul de utilizare
158
concretă a codurilor în documentele de intrare, listele de ieşire, frecvenŃa de utilizare şi gradul

de acomodare a utilizatorului cu sistemul de coduri propus.
Alegerea codului este făcută în funcŃie de dimensiunea şi particularităŃile bazei
informaŃionale, natura, complexitatea şi valorile atributelor, metoda de introducere şi validare
a codurilor cerinŃele şi restricŃiile sistemului informatic proiectat, metoda de calificare, costul
şi timpul de realizare a activităŃilor de codificare.
3. Codificarea atributelor bazei informaŃionale este pentru stabilirea codurilor
corespunzătoare a fiecărui atribut dintre atributele mulŃimii de codificat. În acest scop se
elaborează un catalog al valorii atributelor pe grupe omogene, cu precizarea particularităŃilor
şi valorilor posibile ale acestora. Se va întocmi şi un catalog al tuturor codurilor posibile cu
cifrele de control calculate.
În scopul realizării codificării atributelor bazei informaŃionale la nivelul unei unităŃi
economice se vor avea în vedere următoarele tipuri de atribute:
• conturile sintetice şi analitice din structura planului de conturi cu dezvoltarea
pe trepte ale acestora în funcŃie de specificul activităŃii şi nevoile de informare
operativă
• codificarea materialelor, produselor (sau reperelor) este făcută prin intermediul
unui cod ierarhizat ce să permită atât identificarea variantelor tipologice
posibile de materiale, cât şi stabilirea unei ierarhizări care să asigure raporturile
spre organele ierarhic superioare ale unităŃii economice
• codificarea comportamentelor necesită atribuirea de coduri pentru magazii şi
gestiuni, precum şi coduri pentru secŃii, ateliere şi formaŃii de lucru
• codificarea salariaŃilor este realizată printr-un cod secvenŃial de 4-5 cifre a
cărui lungime va fi determinată de numărul mediu scriptic al personalului din
unitate
• codificarea furnizorilor şi beneficiarilor, care este realizată prin intermediul
unui cod general de ierarhizare stabilit la nivel de economie naŃională
• codificarea unităŃii de măsură se va realiza cu un cod secvenŃial sau
semnificaŃia mnemonică ales astfel încât să servească cât mai bine cerinŃelor de
prelucrare cu calculatorul
• codificarea operaŃiilor tehnologice se va realiza printr-un cod secvenŃial pe
grupe
• codificarea documentelor de intrare şi a situaŃiilor de ieşire se realizează prin
intermediul unor coduri alfabetice, alfanumerice, mnemonice sau cu
semnificaŃie descriptivă, alese în funcŃie de necesitatea noului sistem proiectat
4. Întocmirea catalogului de coduri este realizată prin elaborarea unor liste în care
sunt codurile şi denumirea completă a atributelor la care acestea se referă. Ca să fie folosite
uşor, este recomandabil ca ele să fie ordonate după codul sau denumirea atributelor. Catalogul
de coduri va conŃine denumirea completă a atributelor, codul asociat lor şi alte informaŃii
referitoare la preŃul unitar, unitatea de măsuri precum şi trimiteri la alte clasificări sau
instrucŃiunile de completare.
5. ÎntreŃinerea codurilor, presupune efectuarea de adăugări, modificări sau ştergeri
de atribute în vederea actualizării catalogului de coduri, motiv pentru care este recomandabil
ca această activitate să fie efectuată de aceeaşi echipă ce a făcut clasificarea. Acest catalog
este recomandabil să fie revizuit permanent cu scopul eliminării ambiguităŃii şi a
redundanŃelor prin ştergerea unor valori de atribute ce nu mai prezintă interes. Catalogul se va
actualiza şi în cazul schimbării criteriilor de raportare, a ariei de cuprindere a noului sistem
precum şi în cazul modificării actelor normative.
159
Necesitatea de actualizare şi preluare la diverse niveluri ierarhice au impus elaborarea

de coduri cu valabilitate pe întreaga economie, care să asigure utilizarea lor unitară la nivel
micro şi macro economic.
Această etapizare urmăreşte satisfacerea necesităŃilor de înregistrare, prelucrare şi
analiză, la nivelul de macroeconomie, fiindcă asigură ordonarea sistematică a informaŃiilor pe
baza unor principii şi criterii necesare organelor de sinteză. Pe lângă clasificarea unitară a
produselor şi serviciilor, a fost elaborat un catalog de coduri al unităŃilor de măsură, de tip
numeric format din trei caractere. Pentru etapa de proiectare generală, faza de codificare a
atributelor bazei informaŃionale sunt concretizate în elaborarea structurilor codurilor, ce va
conŃine denumirea atributelor codificate, treptele codului, intervalul de codificare şi unele
trimiteri la catalogul de coduri folosit.
4.10.4. Adaptarea documentelor folosite la cerinŃele noului sistem

Aceasta este una din fazele importante ale proiectării generale, fiindcă în documente
sunt consemnate starea şi dinamica fenomenelor şi proceselor economice desfăşurate în
unităŃile economice. InformaŃiile înscrise în documentele de intrare se vor introduce în
sistemul informatic cu ajutorul unor proceduri manuale sub forma unor date de mişcare ce vor
afecta colecŃiile de date organizate în baze de date.
În funcŃie de sistemul informatic folosit, aceste documente sunt surse de date şi din
acest motiv este sunt denumite practic documente de intrare. Principalul obiectiv al acestei
faze este formularizarea documentelor din punct de vedere al conŃinutului şi formei, astfel
încât să răspundă cerinŃelor unităŃii economice şi exigenŃelor specifice ale sistemului
informatic proiectat. Formatul şi structura formularelor tipizate sunt reglementate unitar la
nivelul economiei naŃionale, urmând ca acestea să fie adoptate la nivelul cerinŃelor unităŃii
economice şi apoi se vor completa cu informaŃii de intrare.
Formularele tipizate sunt elaborate şi codificate în vederea ordonării şi prelucrării cât
mai operative a datelor cu ajutorul calculatorului, pentru simplificarea muncii de evidenŃă şi
reducere a consumul de hârtie. Pentru sistemele informatice, activitatea de adaptare a
documentelor de intrare utilizate ca o principală sursă de creare a structurii fizice a colecŃiilor
de date, se află sub incidenŃa tipurilor de documente tipizate. Atât documentele tipizate cât şi
cele adoptate ulterior la preluarea automată, formează sursă principală de date pentru crearea
şi actualizarea colecŃiilor de date. În funcŃie de acest punct de vedere, documentele de intrare
utilizate într-un sistem informatic asigură crearea iniŃială a colecŃiilor de date şi apoi
actualizarea acestora (adăugare, inserare, modificare şi ştergere) determinate de necesitatea
reflectării imediate a operaŃiilor economice la locul şi în momentul procedurii lor.
Documentele folosite în crearea versiunii iniŃiale a colecŃiilor de date, trebuie să cuprindă
valorile reale ale atributelor destinate constituirii entităŃii bazei informaŃionale, astfel ca ele să
reflecte starea iniŃială a fenomenelor şi proceselor economic cuantificate în momentul
introducerii noului sistem.
Documentele folosite la actualizarea colecŃiilor de date ce trebuie să reflecte operaŃii
economice intervenite în activitatea unităŃii la locul şi în momentul producerii lor, acest lucru
determină operaŃii de adăugare, inserare sau modificare şi ştergere de atribute.
Modificarea formei documentelor de intrare sunt impuse de necesitatea creşterii
facilităŃilor de prelucrare directă a datelor prin intermediul terminalelor şi vizează aspecte ca:
• gruparea în cadrul documentelor de intrare a tuturor atributelor ce urmează a fi
introduse de la terminal, astfel încât să nu fie dispersate pe întreaga suprafaŃă a
documentului
• evitarea intercalării atributelor ce sunt preluate în colecŃiile de date cu cele ce
au caracter constant sau se obŃin prin calcul
160
Proiectarea structurală şi funcŃională a noului sistem informatic
• evidenŃierea în document a numărului maxim de caractere specifice pentru

fiecare atribut, inclusiv precizarea poziŃiei punctului zecimal
• ordinea atributelor în documentul de intrare trebuie să asigure prezenŃa
atributelor de identificare urmate de cele informaŃionale şi terminând cu cele
cantitativ valorice
• scoaterea în evidenŃă a zonelor ce conŃin informaŃii ce se vor prelua în
colecŃiile de date, prin marcarea lor cu linii mai groase sau alte culori, etc…
Rezultatele etapei de proiectare a documentelor de intrare se concretizează “Modelul
documentelor de intrare” ce se finalizează în activitatea de formalizare a datelor din sistemul
proiectat. În cele ce urmează vom prezenta succesiunea şi corelarea fazelor descrise în cadrul
proiectării generale sunt reflectate grafic prin figura 4.18 ce scoate în evidenŃă conexiunea
dintre acestea şi componentele generale ale unui sistem informatic.
4.11. Proiectarea structurală şi funcŃională a noului sistem

informatic
Componentele stabilite în fazele anterioare vor sta la baza definirii structurii şi
funcŃionalităŃii noului sistem informatic. Ele urmează să fie asamblate în conformitate cu
procesul de prelucrare şi algoritmii utilizaŃi în scopul asigurării structurii optime a sistemului
informatic (adică structura sa în subsisteme, aplicaŃii, unităŃi funcŃionale şi unităŃi de
prelucrare).
INTRĂRI IEŞIRI
PRELUCRĂRI
Documente de
intrare Obiectivele sistemu-
lui informatic
SituaŃii de
Proiectarea documente- ieşire
lor de intrare
Atribute calculate
Codificarea atributelor
bazei informaŃionale Atribute preluate
Algoritmi de
Operatori primari calcul
EntităŃile de bază
ConŃinutul bazei
Figura 4.18 Schema corelaŃiilor dintre fazele proiectării generale

Prin faza de proiectare a structurii şi funcŃionalităŃii noului sistem informatic, este
necesară rezolvarea unor probleme ca:
• structurarea sistemului informatic pe subsisteme aplicaŃii şi unităŃi funcŃionale
161
• asigurarea funcŃionalităŃii sistemului proiectat

• definirea organizării prelucrărilor şi a fluxurilor informaŃionale între
compartimentele implicate în noul sistem informatic
a) Structurarea sistemului informatic pe subsisteme aplicaŃii şi unităŃi
funcŃionale se impune prin complexitatea sistemului, priorităŃile solicitate de unitatea
beneficiară, logica prelucrării datelor şi necesitatea specializării activităŃii de prelucrare pe
elemente structurale omogene.
Datorită complexităŃii sistemului, este necesară structurarea sa pe subsisteme, aplicaŃii
şi unităŃi funcŃionale care să asigure abordarea consecventă şi descendentă a proiectării unor
componente omogene şi unitare ce prin asamblare să asigure întreaga arie de cuprindere a
noului sistem informatic.
Subsistemul informatic este o componentă a sistemului informatic ce asigură preluarea
automată a datelor specifice unei funcŃii distincte a unităŃii economice sau a unui domeniu
specific de activitate.
AplicaŃia, rezolvă un grup omogen de lucrări sau probleme ale beneficiarului, cu
observaŃia că un sistem sau subsistemul poate avea mai multe astfel de aplicaŃii.
Unitatea funcŃională este partea componentă a subsistemului sau aplicaŃiei ce
reprezintă un ansamblu omogen şi specific de prelucrări automate destinate rezolvării unei
părŃi din subsistem sau aplicaŃii, fiind formată din intrări specifice, prelucrări omogene şi
ieşiri corespunzătoare rolului şi funcŃiei sale în ansamblul noului sistem informatic.
Unele din avantajele structurării sistemului informatic le menŃionăm în continuare:
• realizarea noului sistem informatic se poate face simultan pentru toate
subsistemele, aplicaŃiile şi unităŃile funcŃionale
• structurarea şi realizarea se poate planifica şi stabilirea unor termene de
realizare, costuri precum şi numărul de membrii implicaŃi în realizarea lor
• modularizarea sistemului prin structurare ce facilitează o concepŃie unitară de
proiectare, inclusiv a modificărilor şi extinderilor ulterioare
• reducerea complexităŃii problemelor abordate de întregul sistem prin
omogenitatea asigurată de subsisteme, aplicaŃii şi unităŃile funcŃionale
componente
• testarea şi lansarea în exploatare a fiecărui subsistem, aplicaŃii şi unitate
funcŃională se va face individual, ce conduce costurile de realizare şi
generalizează experienŃa acumulată asupra întregului colectiv de proiectare
Pe lângă avantajele prezentate trebuie să menŃionăm şi criteriile de bază care stau la
baza structurii sistemului informatic în componentele sale şi acestea sunt:
• omogenitatea activităŃilor sau compartimentelor funcŃionale implicate în
sistemul proiectat
• ciclurile de funcŃionare ale sistemului informatic
• frecvenŃele sau termenele de realizare ale prelucrărilor automate specifice
noului sistem
Omogenitatea activităŃii sau compartimentelor ce sunt implicate în noul sistem,
necesită definirea unei unităŃi funcŃionale pentru fiecare activitate sau compartiment numai în
cazul că prelucrările de date au un caracter unitar. Deci noul sistem proiectat va avea un
număr de aplicaŃii sau unităŃi funcŃionale ce depind direct de tipurile activităŃilor sau egal cu
numărul compartimentelor funcŃionale implicate în acest sistem.
Unul din avantajele unei astfel de structurări constă în uşurinŃa cu care sistemul este
proiectat, acesta datorându-se delimitării exacte a prelucrărilor fiecărei activităŃi sau
compartiment inclusiv facilităŃile de extindere uşoară a noului sistem, prin simpla adăugare de
noi aplicaŃii sau unităŃi funcŃionale. Cel mai mare dezavantaj este realizarea de unităŃi
162
Proiectarea structurală şi funcŃională a noului sistem informatic
funcŃionale complexe şi eterogene din punct de vedere al naturii prelucrărilor sale, datorită
acestui inconvenient acest criteriu se va aplica împreună cu alte criterii.
Ciclurile de funcŃionare ale sistemului informatic definesc natura prelucrărilor
automate ce se realizează în mod recursiv (ciclic) şi constau în crearea iniŃială şi actualizarea
colecŃiilor de date, exploatarea lor şi obŃinerea situaŃiilor solicitate de utilizatorii, inclusiv
realizarea unor interfeŃe cu alte sisteme informatice. Criteriul ne permite structurarea în trei
tipuri de unităŃi funcŃionale, astfel:
• unitate funcŃională de creare iniŃială şi actualizare a colecŃiilor de date –ce
va cuprinde operaŃiile de introducere a datelor în colecŃie, validarea lor,
inclusiv operaŃiilor de conducere la zi a conŃinutului de date;
• unitate funcŃională de exploatare a colecŃiilor de date şi obŃinere a
situaŃiilor de ieşire – ce va conŃine operaŃiile de exploatare a colecŃiilor de
date şi sortarea acestora în funcŃie de necesităŃile beneficiarului;
• unitate funcŃională ce reprezintă interfeŃele cu alte sisteme informatice –
în condiŃiile prelucrărilor distribuite a colecŃiilor de date. InterfaŃa poate fi şi
între două execuŃii succesive ale aceleaşi unităŃi funcŃionale sau pentru
realizarea unor legături între unităŃi funcŃionale distincte.
InterfaŃa este un ansamblu omogen de proceduri şi date care asigură conversia şi
comunicarea între două sau mai multe proceduri succesive. Concret interfeŃele dintre unităŃile
funcŃionale sunt reprezentate de colecŃii de date obŃinute ca ieşiri ale altei unităŃi funcŃionale
şi utilizate în continuare ca intrări într-o altă unitate funcŃională.
Ele se realizează prin procedeul recursivităŃii cumulate conform căruia colecŃiile de
date dintr-o perioadă precedentă devine colecŃie de intrare a perioadelor următoare, procedeu
care se reia la fiecare moment al prelucrării. Ele se realizează în funcŃie de unele condiŃii ale
prelucrării, ce necesită eventual agregarea sau dezagregarea datelor.
FrecvenŃele sau termenele de realizare ale prelucrărilor specific noului sistem sunt
folosite pentru unităŃi funcŃionale ce au prelucrări omogene la anumite termene sau frecvenŃe
fixe. Acestea sunt dependente direct de ritmicitatea obŃinerii situaŃiilor de ieşire, lucru ce
impune gruparea prelucrărilor corespunzătoare în unităŃi funcŃionale distincte. Sunt şi unele
situaŃii în care algoritmul de prelucrare sau de obŃinere a situaŃiilor de ieşire impune o anumită
frecvenŃă de execuŃie într-o anumită perioadă de timp.
Prin folosirea criteriilor amintite la structurarea sistemului în subsisteme şi unităŃi
funcŃionale, se va realiza o structurare de corespunzătoare a noului sistem.
b) Asigurarea funcŃionalităŃii noului sistem, asigură realizarea de corelări cât mai
bune între obiectivele sistemului şi modul concret de asamblare a subsistemelor, aplicaŃiilor şi
unităŃilor funcŃionale astfel încât numărul lor să fie minim iar gradul de prelucrare la maxim.
Prin care se urmăreşte realizarea unei simbioze cât mai naturale şi eficiente între funcŃiile
noului sistem şi modul de informatizare practică a acestora.
Cu ajutorul ei se poate decide în raport de complexitatea noului sistem să se realizeze
subsisteme, aplicaŃii şi unităŃi funcŃionale în raport de natura activităŃilor desfăşurate în
compartimentele funcŃionale ale unităŃii beneficiare.
Unele variante funcŃionale se obŃin din necesitatea asigurării de organizări optime
pentru noul sistem. Ele se datorează multitudinii posibilităŃilor de combinare a subsistemelor,
aplicaŃi şi unităŃilor funcŃionale pentru activităŃile şi compartimentele implicate în noul sistem.
c) Definirea organizării prelucrărilor şi a fluxurilor informaŃionale între
compartimentele implicate în noul sistem. Ea are în vedere elementele structurate ale
unităŃilor funcŃionale şi a modului de legătură între activitatea desfăşurată la compartimentul
de informatică şi compartimentele implicate în noul sistem.
Componentele structurale ale unităŃii funcŃionale sunt definite în succesiunea:
163
1. Sortarea situaŃiilor de ieşire în funcŃie de compartimentele beneficiare,

frecvenŃele şi termenele de realizare ale lor.
2. Verificarea structurii bazei informaŃionale după conŃinutul documentelor de
intrare folosite la introducerea atributelor specifice lor.
3. Certificarea corespondenŃelor dintre structura bazei informaŃionale şi situaŃiile
de ieşire obŃinute cu ajutorul algoritmilor de calcul.
4. Sortarea documentelor de intrare în funcŃie de compartimentele implicate,
frecvenŃele şi termenele de utilizare pentru crearea şi actualizarea colecŃiilor de date.
Stabilirea structurii unităŃilor funcŃionale necesită precizarea intrărilor, prelucrărilor şi
ieşirilor specifice. Fiecărei unităŃi funcŃionale i se atribuie un cod (UF1, UF2,…UFn), având
criteriu de definire frecvenŃa de apelare, interfaŃa cu alte unităŃi funcŃionale şi fluxurilor de
prelucrare specifice.
Cu ajutorul fluxurilor de prelucrare se definesc modurile de combinare dintre
elementele unităŃii funcŃionale şi vor fi codificate pe trei nivele astfel:
F N S
FrecvenŃa fluxurilor de prelucrare;
Numărul unităŃii funcŃionale (UF)
Fluxul de prelucrare a unităŃii funcŃionale.
Elementele structurale ale unităŃii funcŃionale intră în legătură cu compartimentele
funcŃionale cu ajutorul documentelor de intrare sau al situaŃiilor de ieşire, cu scopul realizării
conexiunii dintre unitatea de informatică unde vor fi prelucrate datele şi compartimentele
unităŃii beneficiare în cadrul ansamblului general de organizare a noului sistem.
4.12. Modelarea conceptuală a datelor cu produsele CASE

Automatizarea dezvoltării sistemelor prin instrumente CASE Acronimul CASE
vine de la de la Computer Aided System Engineering şi are ca obiectiv punerea în practică a
produselor-program de proiectare şi realizare a softului cu ajutorul calculatorului.
Instrumentele oferite de CASE (ca de exemplu EXCELERATOR, apărut pe la mijlocul anilor
'80), sunt utilizabile din faza de definire a cerinŃelor până la întreŃinerea fizică a sistemului
informatic, dar prioritate au analiza şi proiectarea bazate pe conceptele şi metodele
structurate. În ultimii ani, acestora li s-au adăugat analiza, proiectarea şi programarea orientată
pe obiecte. Instrumentele CASE implică utilizarea calculatorului ca mijloc de susŃinere a
activităŃilor de planificare, definire, proiectare şi realizare a softului. Ele se bazează pe logica
structurată, pe descompunerea funcŃională şi reprezentarea prin diagrame a fluxurilor de date
ale aplicaŃiilor. Mijloacele CASE realizează proceduri şi metode ce prezintă diferenŃe majore
faŃă de metodele clasice şi care se constituie în performanŃe ale acestor produse.
Pe măsura evoluŃiei lor, sistemele CASE au devenit mai complexe, permiŃând ca
procesele de proiectare şi realizare a aplicaŃiilor să se desfăşoare într-un mediu informatic
interactiv, oferind utilizatorilor un întreg arsenal de instrumente şi proceduri, prin care pot
proiecta, realiza, testa, documenta, întreŃine/actualiza şi exploata sistemul.
Utilizarea sistemelor CASE a început cu introducerea diagramelor fluxurilor de date,
care fac posibilă realizarea unui model al derulării proceselor sistemului/aplicaŃiei care se
proiectează. A urmat folosirea dicŃionarului de date ca un depozit al tuturor datelor privind
sistemul sau aplicaŃia Au apărut ecranele predefinite pentru a prezenta ce poate să obŃină
utilizatorul prin exploatarea sistemului. S-a apelat la facilităŃi grafice, care pot folosi
simbolurile logicii structurate şi care permit proiectantului să realizeze o diagramă coerentă a
fluxurilor de date.
164
Modelarea conceptuală a datelor cu produsele CASE
Primele sisteme CASE erau un set de aplicaŃi neintegrate, cu funcŃii distincte, fără a fi
interconectate. Aceste limite au fost eliminate, în cea mai mare parte, prin generaŃiile actuale,
care încearcă să realizeze o integrare completă şi uşoară a tuturor elementelor, integrarea
reprezentând de fapt, factorul cel mai important al metodologiei CASE. CASE se bazează pe
două funcŃii fundamentale: - prima este bazată pe posibilitatea descompunerii de sus în jos
(top-down) a sistemului informatic în procese şi module distincte, fiecare având definite
responsabilităŃile funcŃionale şi/sau operaŃionale; odată cu orientarea spre obiecte, funcŃiile se
înlocuiesc cu obiectele care îndeplinesc funcŃia, ceea ce uşurează controlul procesului; - a
doua se referă la faptul că sistemele informaŃionale pot fi reprezentate într-o formă grafică
concisă, folosind câteva simboluri de bază. ImportanŃa acestor funcŃii rezidă în posibilitatea
utilizării modularizării aplicaŃiilor, a diagramelor, obŃinerea unei documentaŃii privind
realizarea, evaluarea arhitecturii şi utilizarea sistemului. Pentru definirea şi construirea
sistemelor, produsele CASE presupun stabilirea şi respectarea unei anumite discipline.
Metodologia oferă o interfaŃă între crearea şi verificarea/validarea proiectului logic,
dezvoltarea unei biblioteci cu documentaŃii, care include şi integrează caracteristicile
proceselor şi paşii de parcurs, pentru descrierea modului de lucru; oferă un model al
produsului final, ce poate fi folosit în realizarea operaŃiilor de exploatare şi întreŃinere a
sistemului/aplicaŃiei şi oferă o interfaŃă pentru păstrarea evoluŃiei proiectului. Folosirea
reprezentărilor grafice în logica CASE oferă posibilitatea descompunerii aplicaŃiei în mai
multe componente logice. Prin ataşarea unei baze de date la elementele grafice, se va obŃine
un depozit ce va conŃine paşii şi funcŃiile reprezentate în diagramele construite. Dacă aceste
elemente sunt corect stabilite, ele vor sta la baza descrierii proceselor, ce vor constitui
procedurile de prelucrare a sistemului /aplicaŃiei.
Modelarea grafică în sistemele CASE prezintă o interactivitate ridicată, permiŃând
construirea diagramelor, deplasarea de la o diagramă la alta, modificarea, extinderea,
copierea, evaluarea şi descrierea elementelor unei aplicaŃii. Modelele grafice permit
conectarea fluxurilor logice între activităŃile şi funcŃiile specifice aplicaŃiei, relaŃii care
pot fi testate şi validate în mod automat.
Din punct de vedere al momentului în care a avut loc automatizarea fazelor din ciclul
de viaŃă al sistemelor, se consideră că analiza şi proiectarea reprezintă faze superioare, adică
au fost automatizate mai recent. Instrumentele CASE referitoare la aceste faze se numesc
Upper CASE sau Front End, iar cele referitoare la fazele care au fost automatizate primele
se numesc Lower CASE sau Back End.
CASE realizează două funcŃii principale în modelarea conceptuală a datelor şi anume:
• întreŃinerea diagramelor entitate-relaŃie (DER), astfel ca în orice moment să
reflecte vizual cerinŃele structurale ale datelor;
• legarea obiectelor DER de descrierile lor din depozit.
Majoritatea produselor CASE oferă posibilitatea realizării DER în condiŃiile utilizării
mai multor sisteme de matrice (Chen, Ross, laba-gâştei, etc.).
Elementele modelării conceptuale a datelor incluse într-un depozit sunt următoarele:
- Entity (entitate): - categorie majoră a datelor:
- Name – numele de etichetă unic
- Description – explicaŃia clară a obiectului
- Alias – nume diferit pentru acea entitate
- Primary key – identificatorul unic al entităŃii
- Attributes and repetition – numărul de repetiŃii al atributului
- Abstraction – specificarea super claselor sau subclaselor.
- Attribute (atribute): - caracteristicile entităŃii:
- Name – numele de etichetă al atributului
- Description – descrierea clară a atributului
165
- Domain – valorile posibile ale atributului

- Comutation – formulele de calcul a valorii atributelor
- Aggregation – descompunerea grupărilor de atribute în care ar putea fi
implicat atributul
- Relationship (relaŃie): asocierea dintre entităŃi:
- Name – numele relaŃiei
- Description – explicaŃia relaŃiei
- Degree – numărul entităŃilor implicate în relaŃie
- Cardinality – numărul potenŃial al cazurilor fiecărei entităŃi implicate în
relaŃie
- Inseration rules – reguli economice ce controlează includerea cazurilor
entităŃilor în relaŃie
- Deletion rules – reguli economice de eliminare
CASE dă posibilitatea deplasării la descrierea unui obiect în depozit dacă se face
selecŃia acestuia din DER. Arătăm că informaŃiile introduse în depozit vor fi completate cu
altele în timpul unor etape viitoare.
4.12.1. CASE şi principiile sale

Cele mai edificator este pentru CASE legătura cu Proiectarea Sistemelor/Programarea
asistată de calculator sau cu ajutorul calculatorului, ce are următoarea rădăcină:
COMPUTER AIDED SYSTEM ENGINEERING (CASE).
TendinŃa însă este de a se îmbunătăŃi termenul de System în loc de Software, ce scoate
în relief că CASE poate realiza lucruri mai complexe decât un program.
Obiectul principal al CASE-ului îl constituie punerea în practică a produselor-program
de proiectare şi realizare a softului cu ajutorul calculatorului. Instrumentele oferite de CASE
sunt utilizabile din faza de definire a cerinŃelor până la întreŃinerea fizică a produsului
informatic.
Analiza şi proiectarea bazată pe conceptele şi metodele structurate, reprezintă
elemente forte ale instrumentelor CASE, în ultimul timp CASE acordă atenŃie analizei,
proiectării şi programării orientate pe obiecte.
Mijloacele CASE fac parte din generaŃia conceptuală ce încearcă să reprezinte
proceduri şi metode mult mai fundamentale de proiectare şi realizare a sistemelor de
proiectare şi realizare a sistemelor, cu diferenŃe majore faŃă de metodele clasice, dintre care
amintim [4] [7] [21]:
• prezentarea logicii de proiectare a sistemului
• posibilităŃi de vizualizare a datelor
• sprijin în definirea obiectivelor
• definirea şi utilizarea unor termeni de referinŃă
• uşurinŃa efectuării schimbărilor
• realizarea unei documentaŃii flexibile şi dinamice
• aplicarea unor reguli diversificate de verificare a consistenŃei
• folosirea reprezentărilor grafice simple
• construirea de pseudocoduri structurate
• sprijinirea modularizării
• folosirea pe scară largă a prototipurilor
• constituirea unei interfeŃe pentru generatorul de coduri
• constituirea bibliotecilor de module şi documente
166
Modelarea conceptuală a datelor cu produsele CASE
Sistemele CASE au fost realizate pentru a încuraja abordarea logicii structurale şi

pentru folosirea calculatorului la tezaurizarea lucrărilor şi ca planşetă de desen pe care pot fi
plasate reprezentările structurale ale sistemelor sau aplicaŃiilor.
Produsele de tip CASE au fost cerute de:
• calitatea îndoielnică a aplicaŃiilor clasice
• frustarea utilizatorilor de a participa la procesul de proiectare şi realizare a
aplicaŃiilor, pentru cunoştinŃele ridicate cerute de metodele tradiŃionale
• costurile mari pe care le presupun întreŃinerea şi actualizarea softului
funcŃional
• imposibilitatea rezolvării tuturor cerinŃelor utilizatorului
• limitarea posibilităŃilor de reprezentare grafică a schemelor de realizare a
noilor proiecte
Sistemele CASE au următoarele avantaje [21]:
• reducerea complexităŃii logicii de descriere a sistemului
• posibilitatea de alegere dintre mai multe variante de proiectare
• creşterea vitezei de realizare a sistemelor
• realizarea succesivă a componentelor unui sistem
• creşterea integrării
• consolidarea disciplinei de proiectare
• oferire de interfeŃe de integrare
• folosirea depozitelor modularizate
• salvarea şi refolosirea unor componente din diagramele realizate
• simplificarea activităŃii de proiectare şi realizare a sistemelor/aplicaŃilor
CASE-ul se bazează pe două funcŃii fundamentale:
Prima funcŃie constă în posibilitatea descompunerii de sus în jos ( descendentă sau
Top-Down) a sistemului informatic în procese şi module distincte, fiecare având diferite
responsabilităŃi funcŃionale şi/sau operaŃionale. Conform principiului Divide et impera, s-a
ajuns la concluzia că este mai greu de controlat un sistem prin procesele lui, decât prin
obiectivele componente ale acestora.
1 Modularea sistemului diagramă context
2 Modelarea datelor diagramă entitate-relaŃie
3 Prototipizare sistem prototip de sistem
Modelarea fluxului Modelare procese Elaborare pseudocod

date
Diagramă de structură
Generare aplicaŃie cod-sursă
ÎntreŃinere aplicaŃie
şi reproiectare
Figura 4.19 Etapele ciclului de viaŃă ale lui CASE

A doua funcŃie se referă la faptul că sistemele informaŃionale pot fi reprezentate într-o
formă grafică concisă, folosind câteva simboluri de bază. ImportanŃa funcŃiilor rezidă din
167
posibilitatea folosirii modularizării aplicaŃiilor privind realizarea, evaluare arhitecturii şi

utilizarea sistemului.
Reprezentările grafice în logica CASE-ului, ne dau posibilitatea descompunerii
aplicaŃiei în mai multe componente logice (unităŃi funcŃionale). Ataşând o bază de date la
elementele grafice, se va obŃine un depozit ce va conŃine paşii şi funcŃiile reprezentate în
diagramele constructive.
Graficele în CASE prezintă o interactivitate ridicată, permiŃând construirea
diagramelor, deplasare de la o diagramă la alta, modificarea, extinderea, copierea, evaluarea şi
descrierea elementelor unei aplicaŃii.
Modelele grafice permit conectarea fluxurilor logice între activităŃile şi funcŃiile
specifice aplicaŃiei, relaŃii care pot fi şi validate în mod automat.
4.12.2. Trăsăturile CASE-ului

Are următoarele trăsături de bază:
1. El este văzut ca un set de instrumente folosite în procesul de realizare a softului.
CASE-ul ne fiind un proces independent, va constitui un set integrat de metodologii ce
urmăresc realizarea ciclului de viaŃa al unui sistem. Ciclu de viaŃă al unui sistem îl constituie
verificarea şi validarea activităŃilor de proiectare şi realizare, conform figurii 4.17.
2. Marea varietate a modurilor de lucru ale utilizatorilor conduce la o multitudine de
instrumente CASE, dintre care unele pentru grafice cu o mare diversitate de aplicaŃii
specifice, altele urmăresc controlarea listelor multidimensionale, în timp ce altă categorie
oferă medii de lucru diverse din care utilizatorul poate să opteze pentru o variantă.
3. Simbolurile grafice folosite trebuie să aibă o semnificaŃie predefinită.
4. În fiecare instrument CASE trebuie să fie un sistem de verificare şi validare, anume,
simpla depistare a erorilor.
5. În totalitatea sa CASE-ul trebuie să aibă o derulare bidirecŃională.
6. CASE-urile trebuie să fie deschise pentru a oferi posibilitatea interconectării
instrumentelor CASE ale diverşilor furnizori.
7. Să permită condiŃii de lucru pentru mai mulŃi utilizatori simultan, conform
sistemelor grupurilor de lucru.
8. Multe instrumente, mai ales cele grafice, necesită unele tipuri de facilităŃi în
descompunere.
9. Deplasarea trebuie să fie posibilă, prin trecerile de sus în jos, pe verticală, ale
nivelurilor de descompunere, fie între instrumentele de tip CASE orizontale.
10. Automatizarea poate fi definită de la un instrument CASE la altul sau de la o etapă
din ciclul de viaŃă la alta.
11. Multe componente care asigură mediul de lucru CASE trebuie să fie integrate
unele cu altele.
4.13. Alegerea soluŃiei optime de gestiune a datelor şi a

calculatorului
Aceasta se efectuează cu ajutorul unui model matematic ce trebuie să aibă în vedere
mai multe criterii şi variante posibile.
Modelul matematic ce se va folosi trebuie să rezolve succesiv obiectivul alegerii unei
variante optime prin parcurgerea a trei faze:
168
Alegerea soluŃiei optime de gestiune a datelor şi a calculatorului
• faza întâi –presupune stabilirea unor criterii cantitative sau calitative, pe care
trebuie să le realizeze noul sistem informatic, lucru ce impune o ierarhizare a
acestora;
• faza a doua – consideră mai multe variante de abordare a proiectării de detaliu
cuantificabile în funcŃie de criteriile specifice în faza întâi;
• faza a treia – asigură determinarea variantei optime dintre cele preconizate la
faza a doua pe baza criteriilor de evaluare specificate în faza întâi.
Faza întâi are în vedere mai multe criterii cantitative sau calitative ce se stabilesc
după:
• gradul de dispersie a structurilor organizatorice implicate în funcŃionarea
noului sistem informatic;
• volumul şi frecvenŃa datelor de intrare-ieşire;
• tipul de gestiune al datelor ce se va utiliza pentru noul sistem informatic,
corelat cu tipul de calculator aflat în dotarea unităŃilor beneficiare sau care
urmează a fi achiziŃionat;
• tipul de reacŃie al noului sistem informatic.
Faza a doua consideră mai multe variante de abordare a proiectării de detaliu a noului
sistem informatic stabilindu-se pentru fiecare criteriu valorile corespunzătoare. Valorile
criteriilor pentru variantele preconizate pot avea un anumit optim, care pot fi de tip maxim, de
tip minim sau impus de către conducerea unităŃii beneficiare sau de şeful echipei de
proiectare.
După criteriile de evaluare a noului sistem informatic şi după tipul optim aferent
fiecărui criteriu se vor determina valorile specifice variantelor de abordare a proiectării de
detaliu a noului sistem.
Faza a treia asigură determinarea variantei optime pe baza unui sistem de ponderi
notate “Piv” ce se determină astfel:
1. Dacă criteriul “i” pentru varianta “v” îndeplineşte tipul de optim aferent criteriului,
atunci ponderea va fi notată şi evaluată cu 100 puncte:
Pivoptim =100
2. Dacă criteriului “i” pentru varianta “v” nu îndeplineşte tipul de optim aferent
criteriului, atunci ponderea va fi notată şi evaluată cu zero puncte:
Pivoptim = 0
3. Pentru criteriul “i” corespunzător variantelor “v”aflate între optim şi negativ,
ponderile “Piv” se pot determina mai multe modele, prin folosirea procedee statistice ( acestea
nu se prezintă deoarece nu fac obiectul prezentei cărŃi).
Calitatea variantelor de abordare a proiectării de detaliu depinde de alegerea celui mai
adecvat tip de sistem al gestiunii de date şi de cele mai performante soluŃii de proiectare a
colecŃiilor de date.
4.13.1. Metode de alegere a SGBD-urilor

Alegerea sistemului optim de gestiune a datelor se poate realiza prin intermediul mai
multor metode care au în vedere caracteristicile funcŃionale impuse sistemului proiectat şi
trăsăturile specifice ale fiecărui sistem.
Dacă sistemul dispune de mai multe tipuri de SGBD este recomandabilă alegerea
SGBD-ului optim prin intermediul unor metode de selectare astfel încât să se asigure cel mai
înalt grad al cerinŃelor tehnice ale noului sistem informatic.
Indiferent de metoda adoptată, alegerea unui SGBD este subiectivă, deoarece toate
metodele folosesc anumite criterii de alegere bazate pe un sistem de ponderi ale căror valori
depind de maniera în care administratorul bazei de date acordă o importanŃă mai mare sau mai
169
mică unui criteriu considerat semnificativ din punctul său de vedere. În acest scop, de alegere
cât mai bine a SGBD-ului se folosesc mai multe metode, dintre care unele le vom prezenta în
cele ce urmează.
Metoda SIBLEY presupune alegerea unui SGBD prin compararea cerinŃelor noului
sistem informatic cu caracteristicile funcŃionale ale SGBD-urilor luate în considerare. Se va
alege acel SGBD ce va satisface cel mai mult realizarea practică a cerinŃelor de bază ale
noului sistem informatic.
Metoda PECK permite alegerea unui SGBD în raport de caracteristicile funcŃionale şi
de calitatea acestuia. Caracteristicile se pot grupa în mai multe domenii funcŃionale (ca de
exemplu: organizarea datelor, prelucrarea entităŃilor, interfaŃa dintre date, securitatea şi
protecŃia datelor, etc.), urmând ca pentru fiecare dintre acestea să se acorde o pondere care să
exprime importanŃa relativă a fiecărui domeniu funcŃional. Suma ponderilor astfel atribuite nu
trebuie să depăşească 100. Pentru stabilirea calităŃii SGBD-urilor se mai poate face şi prin
atribute specifice (exemplu: arhitectura, flexibilitatea, facilitatea în utilizare, gradul de
modularizare şi de adaptabilitate a sa la care se acordă un sistem de ponderi ce va exprima
importanŃa relativă a fiecărui criteriu cu specificaŃia că suma acestor ponderi nu poate depăşi
100. Va fi ales acel SGBD care întruneşte punctajul maxim al ponderilor acordate pentru
calitatea şi caracteristicile sale funcŃionale.
Metoda ROSS duce la alegerea SGBD-ului în raport de o listă de criterii ce urmează
caracteristicile sale şi un algoritm de selecŃie bazat pe un sistem de ponderi atribuite fiecărui
criteriu. Fiecărui criteriu i se acordă o pondere între 0 şi 100, iar cuantificarea măsurii în care
un anumit SGBD asigură realizarea unui criteriu se acordă o pondere de la 0 la 10 puncte.
Algoritmul de alegere va calcula produsele dintre ponderile astfel atribuite şi va alege acel
SGBD ce are maximum de punctaj.
Metoda REPERELOR permite alegerea SGBD în situaŃia că beneficiarul vizează un
grup de funcŃii semnificative ale sistemului informatic, ce se numesc repere şi care sunt
asigurate în cel mai înalt grad de acesta.
Metoda SELECłIE permite alegerea unui SGBD prin utilizarea unei liste de
cerinŃele specificate de utilizator şi a alteia cu defectele admise în funcŃionarea acestuia.
Algoritmul alegerii constă în confruntarea maximă a cerinŃelor specifice ale sistemului
informatic şi minimizarea defectelor ce pot apare în funcŃionarea SGBD-ului.
4.14. Etapele de realizare a bazelor de date

Construirea unei baze de date presupune parcurgerea unor etape specifice, cum ar fi:
• analiza domeniului (sistemului) economic pentru care se constituie baza de
date, precum şi a cerinŃelor informaŃionale asociate
• proiectarea structurii (schema conceptuală, externă şi internă) a bazei de date
• încărcarea bazei de date cu date
• exploatarea şi întreŃinerea bazei de date
ConŃinutul etapelor prezentate anterior, activităŃile implicate şi modul lor de
parcurgere depind, în general, de tipul bazei de date ales de proiectant şi de domeniul pentru
care se creează baza de date. Dar, există aspecte cu caracter general care nu sunt influenŃate
de specificul unui anumit domeniu sau care nu depind de tipul bazei de date ales de
proiectant. De aceste aspecte ne vom ocupa în continuare, doar ce priveşte proiectarea
tipurilor de baze de date.
Crearea unei baze de date presupune utilizare unor metode şi tehnici de analiză
specifice (ca: tehnica normalizării relaŃiilor, a diagramelor de dependenŃă riguroasă, etc.), a
unor metode de programare precum şi a unor instrumente de lucru (ca: limbajele de descriere
170
Etapele de realizare a bazelor de date
a datelor -LDD, limbajele de manipulare a datelor -LMD, etc.), care vor fi prezentate în acest
capitol sau în capitolele următoare.
4.14.1. Analiza domeniului economic şi a cerinŃelor informaŃionale

Această analiză presupune următoarele activităŃi [44]:
• analiza componentelor domeniului şi a legăturilor (asocierilor) dintre ele, se
mai numeşte analiză structurală sau statică, pe baza cărei se obŃine modelul
structural (static) al domeniului
• analiza stărilor domeniului şi a tranzacŃiilor posibile între aceste stări, în raport
de anumite evenimente, altfel spus, este analiza temporală (comportamentală),
cu care obŃinem modelul dinamic (temporal) al domeniului
• analiza cerinŃelor informaŃionale sau a transferului de date (tranzacŃiile) ale
domeniului, prin care se satisfac cerinŃele informaŃionale ale factorilor de
decizie. În urma acestei analize se va obŃine modelul funcŃional al domeniului
economic
• integrarea modelelor anterioare (structural, dinamic şi funcŃional) cu scopul
corelării şi completării acestora
În urma rezultatelor aceste etape, se va trece la următoarea etapă de constituire a
bazelor de date, anume la definirea structuri bazei de date. La bazele de date prerelaŃionale
(ierarhice şi reŃea) şi la cele relaŃionale, are o importanŃă deosebită analiza structurală a
domeniului, deoarece aceste tipuri de baze de date reflectă preponderent aspecte structurale
ale domeniului şi mai puŃin cele de dinamică (adică de comportament), respectiv de semantică
(semnificaŃie) a datelor componente. Cele din urmă sunt foarte importante pentru bazele de
date postrelaŃionale (neoclasice), în special pentru bazele de date obiectuale, lucru ce
determină ca analiza temporală şi funcŃională să fie, pentru bazele de date obiectuale la fel de
importantă ca şi analiza structurală.
4.14.2. Proiectarea structurii bazei de date

Modelele obŃinute în urma analizelor domeniului economic sunt modele
informaŃionale, altfel spus, modele ale datelor despre sistem.
Caracteristica principală a modelelor (denumite: modele conceptuale sau semantice)
este faptul că ele sunt independente de instrumentul necesar, adică de SGBD-ul ce le face
operaŃionale.
Important este ca în etapa de analiză a domeniului economic şi a cerinŃelor
informaŃionale asociate, activitatea de modelare a datelor să se facă independent de un SGBD.
Dacă modelare se orientează pe conceptele unui SGBD, acest lucru determină următoarele
dezavantaje [44]:
• la schimbarea SGBD-ului se impune reproiectarea bazei de date
• conceptele SGBD-ului pot influenŃa negativ activitatea de analiză şi de
modelare, prin restricŃiile impuse de acesta, ce pot încuraja sau descuraja
anumite reprezentări
• stabilind ca punct de plecare facilităŃile unui SGBD, utilizatorul
neinformaticean ce nu stăpâneşte acest SGBD nu-şi poate exprima cerinŃele în
deplină cunoaştere de cauză
Proiectarea structuri bazei de date impune luarea în considerare a SGBD-ului care va
implementa şi exploata baza de date.
171
Această structură arată, în fapt un model de date, care este exprimat în conceptul unui
anumit SGBD, lucru ce determină proiectarea structurii bazei de date să arate transpunerea
modelelor conceptuale în termenii unui model de date suportat de un anumit SGBD.
În prezent există o tendinŃă ce se manifestă spre nuanŃarea şi îmbogăŃirea modelelor de
date cu care operează SGBD-urile, determină ca trecerea de la etapa de analiză la cea de
proiectare a structurii bazei de date să fie mai simplă şi mai facil de realizat.
Pentru realizare etapei de proiectare a structurii bazei de date trebuie parcurse
următoarele activităŃi:
• alegerea SGBD-ului
• proiectarea schemei conceptuale a bazei de date
• proiectarea schemei externe sau subschema bazei de date
• proiectarea schemei interne sau de memorare a bazei de date
ActivităŃile prezentate sunt puternic influenŃate de tipul bazei de date ce se va proiecta.
În acest paragraf vom prezenta doar aspectele generale ale activităŃilor, iar elementele
specifice se vor prezenta în cadrul programări SGBD-lui, la tipul de bază de date respectiv, ce
nu este obiectul acestui curs.
4.14.3. Încărcarea datelor în baza de date

În această etapă se realizează popularea masivă cu date a bazei de date. ConŃinutul
acestei etape este relativ simplu, dar activitatea poate fi considerată drept activitate de rutină,
fără dificultate şi creativitate reclamate de activităŃile de analiză şi proiectare. Dar, încărcarea
datelor în baza de date reprezintă este totuşi o activitate dificil de realizat datorită volumului
mare de date care se transferă în baza de date de la diferite surse de date.
Încărcarea bazei de date trebuie să garanteze introducerea numai a datelor corecte şi
aceasta cu un minim de efort, deci cu un minim de parcurgere ale ciclului: validare-corectare.
Sursele de încărcare cu date ale bazei sunt:
• documentele primare
• colecŃii de date ce sunt gestionate prin diverse instrumente informatice, spre
exemplu sistemele de gestiune a fişierelor
Indiferent de unde provin datele, este recomandabil ca la încărcarea bazei de date să se
constituie colecŃii temporare de date (fişiere). Dacă datele se preiau din documentele primare,
atunci este necesară folosirea unor colecŃii temporare pentru deplasarea activităŃii de validare
cât mai repede în procesul de încărcare a datelor în bază. Aceste programe trebuie să conŃină
cât mai puŃine validări, deoarece acestea încetinesc mult execuŃia programelor, determinând
apariŃia unor puncte albe în baza de date, spre exemplu: legături neconstituite datorită
inexistenŃei datelor necesare acestora.
4.14.4. Exploatarea şi întreŃinerea bazei de date

Exploatarea bazei se face de diferiŃi beneficiari finali cu scopul satisfacerii cerinŃelor
de informare ale acestora. SGBD-ul sprijină beneficiarii finali în exploatarea bazei, oferind
diverse mecanisme şi instrumente, spre exemplu: limbajele de manipulare a datelor care ajută
la descrierea cerinŃelor de date ale beneficiarilor finali.
ÎntreŃinerea bazei este o activitate complexă, ce se referă la actualizarea datelor din
bază şi la reproiectarea structurii bazei. Această activitate este realizată de obicei de
administratorul bazei de date. Activitatea aceasta ca şi cea de exploatare a bazei de un SGBD
utilizat, se face prin intermediul unui limbaj de manipulare a datelor şi prin programele
utilitarele ce generează statistici privind activitatea bazei de date.
172
Proiectarea orientată pe obiect (OOD)
Când efortul de întreŃinere a bazei este foarte ridicat se poate lua decizia abandonării
bazei de date şi realizarea alteia noi, care să aibă performanŃe sporite în toate direcŃiile.
4.15. Proiectarea orientată pe obiect (OOD)

Scopul proiectării orientate pe obiect (OOD) este realizarea produsului folosind
obiecte, adică stabilirea claselor şi modelelor care au fort extrase în timpul analizei orientate
pe obiect. Aceasta ar fi implica faptul că OOD este accesibilă doar activităŃilor limbajelor
orientate pe obiect ca şi Smalltalk, C++, Eiffel, Ada 95 şi Java.
Acest lucru însă nu se întâmplă. Deşi e adevărat că OOD nu este suportat de marea
majoritate a limbajelor cunoscute, un aspect larg de OOD poate fi folosit. Aşa cu se explică în
paragrafele anterioare, o clasă este un tip de date abstract cu proprietate de moştenire, un
obiect este o instanŃierea unei clase. Când se foloseşte un limbaj de implementare care nu
suportă proprietatea de moştenire, evoluŃia este utilizarea acelor aspecte ale OOD-ului care
pot fi atinse în limbajul de programare folosit în proiect, adică, utilizarea proiectării tipurilor
de date abstracte (abstract data type design). Tipurile de date abstracte pot fi implementate
virtual în orice limbaj care suportă declaraŃii type.
OOD constă în următorii 4 paşi:
1. Construirea diagramelor de interacŃiune pentru fiecare scenariu
2. Construirea diagramelor claselor detaliate
3. Proiectarea produsului considerând clienŃii obiectelor
4. Trecerea la proiectarea detaliată
Introducerea
în bibliotecă
Generalizare Testare Agregare
Codificare
Proiectarea
modulelor
Specificarea
modulului
Lumea reală
Figura 4.20 Figura ne exemplifică un model al proiectării obiectuale [21]
173
4.16. Tehnici formale pentru proiectarea detaliată

O tehnică pentru proiectarea detaliată a fost deja prezentată şi descriere a prelucrării
pas cu pas a fost dată. Apoi a fost aplicat proiectării detaliate folosind scheme logice
(flowchacts). Pe lângă prelucrările pas cu pas, tehnicile formale pot fi de asemenea, folosite
pentru a îmbunătăŃi proiectarea detaliată. În capitolul 7 se sugerează că implementarea unui
produs complet şi apoi demonstrarea corectitudinii lui ar putea fi subpoductiv. Oricum,
dezvoltând în paralel verificarea şi proiectarea detaliată şi în acelaşi timp testarea cu atenŃie a
codului sunt probleme chiar diferite.
Tehnicile formale în faza de proiectare detaliată se pot implica în 3 moduri: în primul
rând, verificarea corectitudinii deşi nu poate fi aplicată produsului privind ca întreg, poate fi
aplicată modulelor unui produs. În al doilea rând dezvoltarea verificării împreună cu
proiectarea detaliată ar trebui să ducă la o proiectare cu mai puŃine greşeli decât dacă nu s-ar
folosi verificarea corectitudinii. În al 3-lea rând, dacă acelaşi programator este responsabil
atât de proiectarea detaliată cât şi de verificare, cum se întâmplă de obicei, atunci acel
programator va fi sigur că proiectarea detaliată este corectă. Această atitudine potrivită în
legătură cu proiectarea ar trebui să conducă la mai puŃine greşeli în cod.
4.17. Tehnici de proiectare în timp real

Aşa cum s-a explicat anterior, software-ul în timp real este caracterizat de constrângeri
dure de timp, adică de constrângeri de timp de aşa natură că dacă o constrângere nu este
întâlnită informaŃia este pierdută. În particular fiecare import trebuie prelucrat înainte ca
următorul input să sosească. Un exemplu de astfel de sistem este un reactor nuclear controlat
de calculator. Input-uri precum temperatura din interior şi nivelul apei din camera motorului
sunt trimise în mod continuu către calculator care citeşte valorile fiecărui input şi realizează
procesarea necesară înainte ca următoarea intrare să sosească. Un alt exemplu este o unitate
de terapie intensivă controlată de computer. Există 2 tipuri de date despre pacient: informaŃii
de rutină precum sistemul cardiac, temperatura şi tensiunea actuală a fiecărui pacient şi
informaŃii de urgenŃă când sistemul deduce dacă condiŃia unui pacient a devenit critică. Când
astfel de urgenŃe se produc, software-ul trebuie să fie capabil să proceseze input-urile, atât
cele de rutină cât şi cele de urgenŃă de la unul sau mai mulŃi pacienŃi.
O caracteristică a multor sisteme în timp real este aceea că sunt implementate pe
hardware distribuit. De exemplu: software-ul care controlează un avion de luptă poate fi
implementat pe 5 calculatoare, unul pentru a dirija zborul, altul pentru sistemul de arme, al
treilea pentru măsurători electronice, al patrulea pentru a controla sistemul hard al zborului
precum flapsurile aripilor şi motoarele, iar al cincilea pentru a propune tactici în luptă.
Deoarece hardware-ul nu este în totalitate sigur, pot să existe calculatoare adiŃionale care
înlocuiesc automat o unitate care funcŃionează greşit. Nu doar proiectarea unui astfel de
sistem are implicaŃii majore în comunicaŃie, dar problemele legate de timp, pe lângă cele
descrise în paragraful anterior, apar ca o consecinŃă a naturii distribuite a sistemului. De
exemplu: se poate întâmpla ca în condiŃii de luptă computerul de tactică să sugereze ca pilotul
să ia înălŃime, în timp ce computerul care controlează armamentul să recomande ca pilotul să
intre în picaj pentru ca o anumită armă să poată fi lansată în condiŃii optime. Oricum, pilotul
decide să vireze la dreapta, pentru aceasta trimite un semnal computerului care controlează
zborul pentru a face ajustările necesare astfel încât avionul să vireze în direcŃia indicată. Toate
aceste informaŃii trebuie să fie folosite astfel încât mişcarea actuală a avionului să fie
prioritară manevrelor sugerate. Mai mult, mişcarea actuală trebuie să fie în legătură cu
174
Verificarea în timpul fazei de proiectare
computerele de tactică şi de arme astfel încât noile sugestii să fie în condiŃii actuale şi nu
sugerate.
O altă dificultate legată de sistemele în timp real este problema sincronizării. Să
presupunem că un sistem în timp real trebuie să fie implementat pe hardware distribuit.
SituaŃii precum impasul pot apărea când 2 acŃiune au fiecare drept de utilizare exclusiv asupra
unei unităŃi de date şi fiecare are dreptul exclusiv de utilizare asupra unei alte unităŃi de date.
BineînŃeles că impasul nu apare doar în cazul sistemelor în timp real implementate pe
hardware distribuit. Dar generează probleme în special în cazul sistemelor în timp real unde
nu există nici un control asupra ordinii şi a programării input-urilor şi situaŃia poate fi
complicată şi de natura distribuită a hardware-ului. Pe lângă impas (punctul mort) mai pot
apărea şi alte probleme de sincronizare, incluzând condiŃii de competiŃie.
Din aceste exemple, este clar că cea mai mare dificultate cu privire la proiectarea
sistemelor în timp real o constituie asigurarea că constrângerile legate de execuŃia în timp
corespunde cu proiectarea. Adică, tehnicile de proiectare ar trebui să asigure un minimum de
control al faptului că atunci când va fi implementat, proiectul va fi capabil să citească şi să
proceseze datele de intrare la rata corectă
Încă de la începutul erei calculatoarelor, avantajele în tehnologia hardware au depăşit
în aproape orice aspect, avantajele în tehnologia software. Deci, deşi hardware-ul există
pentru a manevra orice aspect al sistemelor în timp real descrise mai sus, tehnologia de
proiectare software a rămas cu mult în urmă. În câteva aspecte ale ingineriei software în timp
real, au fost făcute progrese importante. De exemplu: multe dintre specificaŃiile tehnice pot fi
folosite pentru a specifica sistemele în timp real. Din nefericire proiectarea software nu a atins
acelaşi grad de sofisticare. Au fost făcuŃi paşi mari, dar starea curentă nu se poate compara
încă cu modificările legate de specificaŃiile tehnice deoarece aproape orice tehnică de
proiectare pentru sisteme în timp real este preferabilă în locul nici unei tehnici, un număr de
tehnici de proiectare în timp real sunt folosite în practică. Dar este un drum lung până când va
fi posibilă proiectarea sistemelor în timp real aşa cum a fost descrisă anterior şi până când va
exista certitudinea că sistemul să fie implementat, orice constrângere de timp va fi realizată şi
nu vor apărea probleme legate de proiectare.
Cele mai multe tehnici de proiectare în timp real sunt extensii ale tehnicilor în timp
nereal, către domeniul în timp real. De exemplu: dezvoltarea structurată pentru sistemele în
timp real (SDRTS) este în mod esenŃial o extensie a analizei sistemelor structurate, a analizei
fluxului de date şi a analizei tranzacŃiilor către software-ul în timp real. Tehnicile de
dezvoltare include o componentă pentru proiectarea în timp real. Altă extensie a aceluiaşi
grup de tehnici pentru domeniul în timp real este proiectarea accesului pentru sisteme în timp
real (DARTS - design approach for real time systems). Reducerea costului software (SCR -
software cost reduction) este o tehnică de proiectare în timp real bazată pe conceptul
ascunderii informaŃiei.
Aşa cum s-a prezentat, din păcate, starea la care se află proiectarea în timp real nu este
atât de asumată precum s-ar dori. Cu toate acestea se fac eforturi asidue pentru a îmbunătăŃi
situaŃia prezentată.
4.18. Verificarea în timpul fazei de proiectare

Scopul testării în faza de proiectare este de a verifica dacă specificaŃiile au fost
încorporate corect şi complet în proiect şi de a asigura corectitudinea proiectării. De exemplu:
proiectarea nu trebuie să aibă greşeli logice şi toate interfeŃele trebuie definite corect. Este
important ca fiecare greşeală a proiectării să fie detectată înainte de a se începe codificarea,
altfel costul reparării greşelilor vor fi considerabil mai mari. Detectarea greşelilor de
175
proiectare poate fi realizată prin mijloace de examinare a proiectului, precum şi prin

proiectarea de căi de acces. Examinarea proiectului este prezentată la urma acestei secŃiuni,
dar observaŃiile pot fi aplicate în mod egal proiectării căilor de acces.
Examinarea proiectului este similară cu examinarea fazei de specificaŃie cu excepŃia că
reprezentanŃii organizaŃiei client nu sunt de obicei prezenŃi la examinarea proiectului. Aceasta
este o consecinŃă a faptului că persoanele care nu au cunoştinŃe tehnice consideră documentele
de proiectare ca fiind mai grele de înŃeles decât cele de specificaŃie
Când produsul este orientat pe tranzacŃii, examinarea proiectului trebuie să reflecte
acest lucru. Examinările care vor include toate tipurile de tranzacŃii posibile trebuie să fie
programate.
Impactul trebuie să lege fiecare tranzacŃie din proiect la specificaŃie, arătând cum
tranzacŃia rezultă din documentul de specificaŃie. De exemplu: dacă aplicaŃia este un
bancomat (ATM – automated teller machine), o tranzacŃie va corespunde fiecărei operaŃii pe
care clientul o realizează, precum depozite sau strategii din contul de card. În alte situaŃii,
corespondenŃa dintre specificaŃii şi tranzacŃii nu va fi în mod necesar unu la unu. Într-un
sistem de semafoare, de exemplu, conducerea unui automobil este un sistem al drumului
determină ca sistemul să decidă schimbarea unei anumite lumini roşii în verde în 15 secunde
şi apoi următoarele impulsuri de la acelaşi senzor pot fi ignorate. În sens contrar, pentru a
accelera fluxul traficului, un singur impuls poate cauza schimbarea din roşu în verde a unei
serii de lumini.
Restrângerea inspecŃiilor la cele bazate pe tranzacŃii ar determina nedetectarea
situaŃiilor în care proiectanŃii au omis anumite aspecte ale tranzacŃiilor cerute de specificaŃii.
Examinările bazate pe specificaŃii sunt, de asemenea, esenŃiale pentru a asigura că nici o
declaraŃie din documentul de specificaŃie nu a fost omisă sau interpretată greşit.
4.19. Documentul de specificaŃii

În mod virtual, fiecare document de specificaŃii conŃine constrângeri ce trebuie
satisfăcute de către produs. Aproape totdeauna există un termen limită pentru livrarea
produsului. O altă stipulaŃie uzuală este “produsul trebuie astfel instalat încât să poată rula în
paralel cu unul deja existent” până ce clientul este convins că produsul satisface într-adevăr
fiecare aspect al documentului de specificaŃii. Alte constrângeri pot include portabilitatea,
deci că produsul construit trebuie să poată rula pe orice alt hardware sub acelaşi sistem de
operare sau sub o varietate de sisteme de operare diferite. O altă constrângere ar putea fi
fiabilitatea. Dacă produsul trebuie să monitorizeze pacienŃi într-o unitate de terapie intensivă
este de importanŃă maximă să fie operaŃional 24 de ore pe zi. O altă cerere ai fi timpul rapid
de răspuns. O constrângere tipică în această categorie at putea fi “la 95% din toate întrebările
de tip 4 ar trebui să se răspundă în 0.25 de secunde”. Multe constrângeri în ceea ce priveşte
timpul de răspuns trebuie exprimate în termeni probabilistici pentru că timpul de răspuns
depinde de încărcarea curentă a calculatorului. Spre deosebire de aceasta, aşa numita
constrângere în timp real se exprimă în termeni absoluŃi. De exemplu: este inutil să dezvolŃi
un software care informează pilotul unui avion de luptă despre o rachetă care soseşte în 0.25
secunde cu un procentaj de 95% - produsul trebuie să aibă un procentaj de 100%.
O componentă vitală a documentului de specificaŃii este setul de criterii de acceptare.
Este important din punctul de vedere al clientului şi al dezvoltătorului să realizeze o serie de
teste ce vor fi folosite mai târziu la probarea faptului că produsul satisface într-adevăr
specificaŃiile lui şi că sarcina dezvoltătorului a fost îndeplinită. Unele din criteriile de
acceptare pot fi reformulări ale constrângerilor, având în vedere că altele vor adresa diferite
rezolvări. De exemplu: clientul ar putea furniza dezvoltătorilor o descriere a informaŃiei cu
176
ComparaŃia tehnicilor de specificaŃii
care va lucra produsul. Un criteriu de acceptare potrivit ar fi acela că produsul va procesa

corect datele de acest tip şi va elimina cele eronate.
Documentul de specificaŃii este un contract între client şi dezvoltător. El specifică
precis ce trebuie să facă produsul şi care sunt constrângerile lui. Odată de echipa de
dezvoltare a înŃeles perfect problema, pot fi sugerate strategii cu soluŃii posibile. O strategie
de rezolvare este o apropiere generală în construirea produsului. De exemplu: o strategie
posibilă de rezolvare pentru un produs ar fi folosirea unei baze de date online, o altă ar fi
utilizarea fişierelor convenŃionale şi extragerea informaŃiei cerute folosind rulări simultane de
pachete. Când determine strategii de rezolvare, este bine să le elaborezi fără să iei în
considerare constrângerile din documentul de specificaŃii. Apoi, pot fi evaluate în funcŃie de
constrângeri o varietate de strategii de rezolvare, putându-se face modificările necesare.
Există mai multe căi de a determina dacă o strategie de rezolvare va satisface cerinŃele
clientului. O cale evidentă este realizarea de prototipuri, care poate fi o tehnică bună pentru
rezolvarea problemelor referitoare la interfeŃele cu utilizatorul şi constrângerile de timp. Alte
tehnici de determinare dacă cererile sunt satisfăcute includ simularea şi modelarea analitică a
reŃelei.
În timpul procesului, vor fi folosite un număr de strategii de rezolvare la care se va
renunŃa mai apoi. Este important ca să se Ńină o înregistrare scrisă despre strategiile la care s-a
renunŃat, incluzând şi motivele. Aceasta va ajuta echipa de dezvoltare în justificarea strategiei
alese. Dar şi mai important este faptul că există un pericol omniprezent în timpul fazei de
întreŃinere concretizat în faptul că procesul de intensificare va fi acompaniat de încercări de a
veni cu o strategie de rezolvare nouă şi pripită. De aceea existenŃa înregistrării scrise este
foarte folositoare în timpul întreŃinerii.
Până la acest punct, echipa de dezvoltare ar avea determinate una sau mai multe
strategii de rezolvare posibile care satisfac constrângerile. O decizie în două etape trebuie
luată acum. Prima: dacă clientul este sfătuit să computerizeze şi dacă da, care strategie de
rezolvare viabilă trebuie adoptată. Răspunsul la prima întrebare poate fi cel mai bine
determinat pe baza analizei cost-profit. A doua: dacă clientul decide să demareze proiectul, el
trebuie să informeze echipa de dezvoltare asupra criteriilor de optimizare folosite, cum ar fi
minimizarea costului total pentru client sau maximizarea returnării investiŃiei. Dezvoltătorii
vor atenŃiona clientul despre strategia de rezolvare cea mai viabilă care satisface criteriul de
optimizare.
4.20. ComparaŃia tehnicilor de specificaŃii

LecŃia principală a acestui capitol este aceea că orice firme e de dezvoltare trebuie să
decidă ce tip de limbaj de specificaŃii este potrivit pentru produsul ce urmează a fi dezvoltat.
O tehnică neformală este uşor de învăŃat, dar nu are puterea unei tehnici semiformale sau
formale. Invers, fiecare tehnică formală suportă o varietate de trăsături caracteristice care pot
include executabilitatea, probarea corectitudinii sau transformabilitatea pentru a proiectarea şi
implementarea printr-o serie de paşi ce conservă corectitudinea. Deşi este în general adevărat
că cu cât tehnica este mai formală cu atât este mai puternică, este de asemenea adevărat că
tehnicile formale pot fi dificil de învăŃat şi de folosit. De asemenea, o specificaŃie formală
poate fi greu de înŃeles pentru client. Cu alte cuvinte, există o permanentă controversă între
comoditatea folosirii şi puterea unui limbaj de specificaŃii.
În unele cazuri, alegerea unui tip de limbaj de specificaŃii este uşoară. De exemplu:
dacă marea majoritate a membrilor echipei de dezvoltare nu au nici un antrenament în ştiinŃa
calculatorului, atunci este virtual imposibil să foloseşti orice altceva decât o tehnică de
specificaŃii neformală sau semiformală. Invers, unde se construieşte într-un laborator de
177
cercetare un sistem cu misiunea critică de a acŃiona în timp real, puterea tehnicii de

specificaŃii formală va fi cu siguranŃă cerută.
Un factor adiacent care complică lucrurile este că multe dintre noile tehnici formale n-
au fost testate în condiŃii practice, fiind deci un considerabil risc în folosirea unei astfel de
tehnici. Mari sume de bani vor fi necesare pentru antrenamentul membrilor importanŃi ai
echipei de dezvoltare, mai mulŃi bani fiind cheltuiŃi când echipa va ajusta limbajul care l-a
învăŃat în clasă la actualul proiect. S-ar putea întâmpla de asemenea ca instrumentele software
ce susŃin limbajul să nu funcŃioneze adecvat, aşa cum s-a întâmplat cu SREM, cu cheltuieli
adiŃionale rezultate şi depăşirea timpului. Dar dacă totul merge şi planul de conducere a
proiectului software ia în considerare timpul adiŃional şi banii necesari când o nouă tehnologie
este folosită pentru prima dată la un proiect mai deosebit sunt posibile câştiguri imense.
Ce tehnică de specificaŃii trebuie folosită pentru un anumit proiect? Depinde de
proiect, de echipa de dezvoltare, echipa de conducere şi de un miliard de alŃi factori cum ar fi
insistenŃa clientului ca o metodă anume să fie folosită (sau să nu fie folosită). Aşa că atât de
multe alte aspecte ale ingineriei software, trebuie realizate negocieri, din păcate, nu există o
regulă simplă în ceea ce priveşte folosirea unei tehnici de specificaŃii.
4.21. Instrumente CASE pentru faza de specificaŃii

Două clase de instrumente CASE sunt în mod particular folositore în faza
specificaŃiilor. Primul este instrumentul grafic. Dacă produsul este reprezentat folosind
diagrame pentru fluxul de date (DFD), reŃele Petri, diagrame de relaŃii între entităŃi sau oricare
din multele reprezentări omise din această carte doar din motive de spaŃiu, trasarea întregului
produs de mână este un proces lung. În plus, făcând schimbări substanŃiale va rezulta
necesitatea de a redesena totul de la început. Având un instrument de desenat, se va economisi
deci mult timp. Instrumente de acest tip există pentru tehnicile de specificaŃii descrise în acest
capitol la fel ca şi pentru alte reprezentări grafice a specificaŃiilor. Un al doilea instrument
necesar în timpul acestei faze este dicŃionarul de date. Aşa cum s-a menŃionat anterior, acesta
este un instrument care stochează numele şi reprezentarea (formatul) fiecărei componente din
alineatele de date ale produsului, incluzând fluxurile de date şi componentele lor, stocajele de
date şi componentele lor, procesele şi variabilele lor interne. Din nou, există o mare varietate
de dicŃionare de date care lucrează pe o varietate de harduri.
Este neobişnuit ca o tehnică de specificaŃii să recepŃioneze o acceptare larg
răspândită, doar dacă există un mediu bogat de instrumente CASE care susŃin tehnica. De
exemplu: SREM va fi probabil mult mai folosit astăzi, având REVS-setul de instrumente
CASE asociat reprezentat mai bine în testele US Air Force. Nu este uşor nici pentru
profesionişti cu experienŃă software a specifica sistemul corect. Este mai acceptabil a asigura
specificatori cu un set de instrumente CASE pentru că implementarea ajută în toate felurile
posibile.
4.22. Metrici pentru faza de specificaŃii

La fel ca şi în celelalte faze, în timpul fazei de specificaŃii este necesar să se
măsoare cele 5 metrici fundamentale: mărime, cost, durată, efort şi calitate. O măsură a
mărimii specificaŃiei este numărul de pagini din documentul de specificaŃii. Deci, dacă aceeaşi
tehnică este folosită pentru specificarea unui număr de produse, atunci diferenŃele în mărimea
specificaŃiei pot fi indicatori semnificativi ai efortului necesar în construcŃia produselor.
178
Prototipizarea rapidă ca o tehnică de specificaŃie
Referindu-ne la calitate, un aspect vital al inspecŃiilor specificaŃiei este înregistrarea

statisticilor greşelilor. Notarea numărului de greşeli de fiecare tip găsite în timpul inspecŃiei
este o parte integrantă a procesului de inspecŃie. De asemenea, rata de detectare a greşelilor
poate da o măsură a eficienŃei procesului de inspecŃie. Metricile pentru prezicerea mărimii
produsului final includ numărul de alineate din dicŃionarul de date. Ar trebui luate în
considerare mai multe puncte diferite, incluzând numărul de fişiere, alineate de date, procese,
etc. Această informaŃie poate de conducerii o estimare preliminară privind efortul necesar în
construcŃia produsului. Este important notarea faptului ca această informaŃie va constitui o
probă la nivel maxim. Cu toate acestea, în timpul fazei de design un proces într-un DFD poate
fi împărŃit într-un număr de module diferite. Invers, un număr de procese se pot constitui
împreună într-un singur modul. Deci, metricile derivate din dicŃionare de date pot da
conducerii un indiciu timpuriu despre eventuala mărime a produsului final.
4.23. Prototipizarea rapidă ca o tehnică de specificaŃie

Forma convenŃională a modelului de prototipizare rapidă, după cum s-a descris
anterior sunt paşii de implementare şi integrare vor fi efectuaŃi în general în paralel. Prototipul
rapid este folosit singur ca un mijloc de a determina nevoile clientului exact şi este înlăturat
după ce clientul semnează specificaŃiile. Adică prototipizarea rapidă este folosită ca o tehnică
de analiză a necesităŃilor. O a doua abordare este să te descurci fără specificaŃii şi să foloseşti
prototipul rapid însuşi decât specificaŃiile sau o parte semnificativă a specificaŃiilor. Această
abordare oferă atât viteză cât şi exactitate. Nu se pierde timpul pentru a întocmi specificaŃii
scrise şi dificultăŃile asociate cu specificaŃiile ca ambiguităŃile, omisiunile şi contradicŃiile nu
pot apărea. În schimb, pentru că prototipul rapid constituie specificaŃiile, ceea ce trebuie făcut
este să stabileşti că produsul va face ceea ce face prototipul rapid şi să înregistrezi orice
trăsături suplimentare pe care produsul trebui să le sprijine ca actualizarea fişierelor,
securitatea şi tratarea erorilor.
Această versiune a modelului de prototipizare rapidă poate avea un neajuns major.
Dacă există o neînŃelegere ca dacă cei care dezvoltă software s-au achitat satisfăcător de
obligaŃiile lor, este improbabil ca un prototip rapid să se menŃină ca o declaraŃie legală a unui
contract între cel care dezvoltă software şi client. Pentru acest motiv, folosirea prototipului
rapid ca o singură specificaŃie nu ar trebui făcută niciodată, nici dacă software-ul este
dezvoltat intern (adică când clientul şi cei care dezvoltă software sunt membri ai aceleiaşi
firme). În cele din urmă, este improbabil ca conducătorul de managementul de investiŃii a unei
bănci să ia decizia de procesare a datelor la tribunal. Totuşi, pentru a se proteja, cei care
dezvoltă software-ul nu trebuie să folosească prototipul rapid ca specificaŃii chiar când
software-l este dezvoltat intern. Un al doilea motiv pentru care prototipul rapid nu ar trebui să
ia locul specificaŃiilor scrise este problemele potenŃiale cu întreŃinerea. Pentru că nu există
specificaŃii scrise, în timpul fazei de întreŃinere specificaŃiile curente sunt simplu versiunea
curentă a produsului şi schimbările specificaŃiilor trebuie făcute în termenii funcŃionalităŃii
versiunii curente a produsului. ÎntreŃinerea este dezirabilă chiar când este disponibilă toată
documentaŃia şi actualizată. Dacă nu există specificaŃii, întreŃinerea poate deveni rapid un
coşmar. Problema este acută în particular în cazul măririi, unde trebuie implementate
schimbări în necesităŃi. Poate fi foarte dificil să schimbi documentele de proiectare pentru a
reflecta noile specificaŃii pentru că, în absenŃa specificaŃiilor scrise, echipa de întreŃinere nu va
avea o situaŃie clară a specificaŃiilor curente. Pentru amândouă aceste motive, prototipul rapid
trebuie folosit simplu ca o tehnică de analiză a necesităŃilor, adică, ca un mijloc de
determinare nevoile reale ale clientului. În consecinŃă, documentele de specificaŃie scrise
trebuie produse folosind prototipul rapid ca o bază.
179
4.24. ImplicaŃiile manageriale ale modelului de prototip rapid

O problemă a prototipurilor rapide este faptul că comoditatea cu care schimbările care
pot fi în general aplicate prototipurilor rapide pot încuraja clientul să ceară tot felul de
schimbări importante pentru versiunea de produs operaŃional livrat. Totodată, clientul se poate
aştepta ca schimbările să fie implementate la fel de rapid ca şi cum ar fi schimbări aplicate
prototipului rapid. Aceasta a fost experienŃa autorului cu SIM-ul descris anterior.
La introducerea oricărei noi tehnologii, înainte ca o firmă să folosească modelul
prototipului rapid este vitală avertizarea conducerii în privinŃa avantajelor şi dezavantajelor
prototipurilor rapide. Cu toată corectitudinea, deşi prototipul rapid este puternic şi bun, mai
pot exista îndoieli în această privinŃă. Pe lângă punctele slabe arătate anterior, s-au descoperit
că produsele cărora li se aplică prototipurile sunt mai greu de integrat decât produsele
specificate. Comoditatea integrării este importantă pentru produsele pe scară largă, în special
CCCCI (comandă, control, comunicare, calcul şi inteligenŃă) software. Două aspecte ale
prototipurilor rapide trebuie luate în considerare de orice manager. În paragrafele anterioare a
fost indicată o privire rapidă pentru a transforma un prototip rapid într-un produs final. Un
prototip rapid ar trebui folosit exclusiv ca un sens al determinării clare a cerinŃelor clientului.
Al doilea aspect important este că în anumite circumstanŃe, prototipul rapid poate lua
locul fazei specificaŃiilor, nu poate înlocui niciodată faza proiectării. O echipă poate folosi cu
siguranŃă informaŃia şi experienŃa dobândită de la prototipul rapid ca un ghid în realizarea
unui proiect bun. Cu toate acestea, deoarece prototipul rapid este realizat în grabă, e
neobişnuit ca un prototip rapid să aibă un bun design.
Prototipare rapidă NecesităŃile schimbate
Verificare Verificare
Faza de specificaŃii
Verificare
Faza de proiectare
Verificare
Dezvoltare
Faza de implementare
ÎntreŃinere
Test
Faza de integrare
Test
Modul de operaŃii
Retragere
Figura 4.21 Modelul de prototipizare
180
ImplicaŃiile manageriale ale modelului de prototip rapid
Un rezultat mai important este acela că de fapt conducerea modelului de prototip rapid
cere o schimbare majoră a concepŃiei pentru managerul care este obişnuit să conducă numai
modelul de tip cascadă. ConcepŃia de la baza modelului de tip cascadă este de a face lucrurile
corect de la început. Desigur, modelul de tip cascadă încorporează bucle de feedback dacă
echipa nu atinge acest scop (scopul se atinge oricum rar). Idealul pentru echipa care realizează
modelul de tip cascadă este executarea fiecărei faze a procesului de dezvoltare o singură dată.
În schimb, prototipul rapid este specific construit pentru schimbări frecvente. Acest concept
este diametral opus apropierii cu care un manager este obişnuit. Apropierea prototipului rapid
constă în realizarea mai multor iteraŃii care ne dau un model mai realist decât cel obŃinut de
cel de tip cascadă. Această logică poate convinge un manager să folosească modelul de
prototip rapid.
Un alt aspect al modelului de prototip rapid care cere o abordare diferită din partea
managerului este creşterea interacŃiunii între client şi echipa ce realizează dezvoltarea, în
particular echipa prototipului rapid. În cazul modelului de tip cascadă, interacŃiunea dintre
client şi echipa de dezvoltare este restricŃionată la o serie de interviuri între echipa care preia
cererile şi client sau angajaŃii lui/ei. Când un prototip rapid este folosit, există aproape o
continuă interacŃiune între echipa prototipului şi echipa clientului, până când prototipul rapid
este acceptat.
NecesităŃile schimbate
Verificare
Prototipare rapidã
Verificare
Faza de proiectare
Verificare
Faza de
implementare
Faza de integrare
Test
Modul de operaŃii
Retragere
Figura 4.22 Prototipizare rapidă servind ca specificaŃie
181

1. Care sunt procesele de modelare succesivă în proiectare?
2. Care sunt etapele proiectării sistemelor stabilite de metodologie?
3. Care sunt cerinŃele metodologiei de proiectare a sistemelor informatic?
4. Care sunt părŃile în care se descompune un sistem informatic?
5. Care sunt strategiile arhitecturi sistemelor informatice?
6. Care sunt etapele specifice managementului proiectării?
7. Care sunt etapele folosite de modelul în cascadă?
8. Care sunt paşii folosiŃi de modelul V?
9. Care sunt avantajele modelului incrementat?
10. Care sunt etapele modelului fântână arteziană?
11. Care sunt componentele modelului piramidă?
12. Ce conŃine raportul analizei de sistem?
13. Ce tipuri de BD se pot proiecta?
14. Ce rol are administratorul BD?
15. Care e structura planului de bază al proiectării?
16. Ce obiective se pot detalia pentru sistemele informatice?
17. Ce fel de DER se parcurg pentru modelarea datelor?
18. Ce este o entitate?
19. Ce notaŃii foloseşte ROSS?
20. Ce notaŃii sunt folosite de LBMS?
21. Ce trebuie să conŃină o situaŃie de ieşire?
22. Care sunt fazele de proiectare a bazei informaŃionale?
23. Care sunt submulŃimile necesare BD pentru varianta ieşiri-intrări?
24. Care sunt condiŃiile de proiectare directă cu conŃinutul bazei informaŃionale?
25. Care sunt algoritmii şi modelele logicii proceselor în proiectare?
26. Câte feluri de entităŃi sunt?
27. Care sunt componentele entităŃii compuse?
28. Care sunt atributele privite din puncte de vedere al stabilităŃii?
29. Ce tipuri de corespondenŃă avem?
30. Care sunt fazele stabilirii structurii bazei informaŃionale cu modelul EAC?
31. Care sunt avantajele codificării în prelucrarea automată?
32. Care sunt codurile elementare?
33. Care sunt codurile complexe?
34. Care sunt metodele de calcul al cifrei de control?
35. Ce reprezintă codurile autocorectoare de erori?
36. Care sunt fazele pentru codificarea atributelor bazei informaŃionale?
37. Ce aspecte vizează modificarea formei documentelor de intrare?
38. Ce probleme rezolvă faza de proiectare a structurii funcŃionalităŃii noului sistem?
39. Care sunt criteriile de structurare a sistemelor informatice?
40. Care sunt componentele structurale ale unităŃii funcŃionale?
41. Care sunt principalele funcŃii CASE?
42. Care sunt elementele depozitelor CASE?
43. Care sunt avantajele sistemelor CASE?
44. Care sunt metodele de alegere a SGBD-urilor?
45. Care sunt etapele de construire a unei baze de date?
46. Ce activităŃi presupune analiza domeniului economic?
47. Ce etape parcurg în proiectarea structurii bazei de date?
48. Care sunt paşii proiectării orientate obiect?
182
5.
Capitolul
5 Elemente ale proiectării orientate pe obiect
5.1. Premisele orientării obiectuale

Tehnicile orientate obiect îşi au originea la începutul anilor 80. Lucrările de referinŃă
ce tratează metodele de analiză şi proiectare orientate obiect au apărut începând cu 1988.
În paralel, utilizarea programării vizuale a determinat creşterea nivelului de
abstractizare, extinderea posibilităŃilor de exprimare, automatizarea trecerii de la proiectare la
implementare, definirea unor modalităŃi sporite de verificare. Simbolurile grafice şi
automatizarea activităŃilor întreprinse permit o înŃelegere mai bună a domeniului aplicaŃiei, o
apropiere chiar a nespecialiştilor în informatică de utilizarea tehnicii de calcul.
Azi, o serie de limbaje sunt extinse să lucreze cu obiecte, cu biblioteci ce au obiecte
predefinite pentru utilizatori şi oferă posibilitatea de a defini noi clase de obiecte, mai mult
instrumentele, mediile, CASE-urile şi SGBD-urile sunt orientate obiect.
Majoritatea modelelor orientate obiect utilizate în prezent, sunt o colecŃie de tehnici şi
convenŃii grafice de reprezentare şi tind să se cristalizeze în metode complete având ca obiect
principal îmbunătăŃirea construcŃiei sistemelor complexe, plecând de la urătoarele trei
dimensiuni: funcŃie, comportament şi date.
O justificare succintă a abordării orientate obiect este [4]:
• necesitatea unor schimbări în metodele şi tehnicile de elaborare a produselor
soft, cerute de costurile ridicate şi calitatea scăzută a acestora, faŃă de
produsele hard
• necesitatea de a avea interfeŃe simple, prietenoase cu utilizatorul şi de a le
realiza uşor
• necesitatea de a realiza produse program uşor de întreŃinut
Obiectivele abordării orientate obiect sunt:
• obiectivul general al metodei orientate obiect este cristalizarea unor convenŃii
şi tehnici de aplicare a acestor metode, în seturi complete care să să ajute, să
faciliteze îmbunătăŃirea construirii sistemelor complexe plecând de la cele trei
componente care sunt aplicate în toate etapele ciclului de realizare
• obiectivul analizei orientate obiect îl constituie descrierea completă şi corectă a
sistemului, spre deosebire de metodele tradiŃionale, care separă modelarea
datelor de modelarea prelucrărilor, iar metodologiile orientate obiect se
caracterizează prin iterare în obŃinerea unor ierarhii de clase de obiecte, care
capturează atât date cât şi comportament
• obiectivul proiectării orientat obiect este de a rafina modelele de analiză, având
în vedere soluŃia de implementare aleasă
Una dintre cele mai cunoscute metode şi utilizată la orientarea obiect este OMT, care a
fost elaborată de RUMBAUGH şi BLAHA. Spre deosebire de alte metode, este o înşiruire de
183
paşi pentru analiză şi/sau proiectare de aplicaŃii informatice. OMT-ul cuprinde toate etapele
ciclului de realizare şi anume: analiză, proiectare şi implementare.
Are avantajul că foloseşte aceleaşi notaŃii pentru modelarea întregului ciclu de viaŃă al
sistemului, astfel că nu este necesară trecerea la alte notaŃii sau interpretări ale semanticii în
diferite etape de realizare.
Metoda OMT are dezavantajul că nu oferă o ghidare suficientă în etapele timpurii ale
procesului de dezvoltare al sistemului.
OMT-ul, comparativ cu celelalte metode, prezintă o mare varietate de concepte, bine
definite, precum şi legături ce pot exista între anumite concepte.
Un neajuns fundamental a abordărilor orientate pe date şi a celor orientate pe acŃiuni
este aceea că datele şi acŃiunile sunt cele 2 feŃe ale unei monede: un alineat de date nu poate fi
schimbat decât dacă o acŃiune se efectuează asupra lui, iar acŃiunile fără date asociate lor sunt
lipsite de sens. De aceea, sunt necesare tehnicile care acordă aceeaşi importanŃă datelor şi
acŃiunilor. Acest lucru este realizat de tehnicile orientate obiect. La urma urmei, un obiect
cuprinde atât datele cât şi acŃiunile. Să ne reamintim că un obiect este un exemplu a unui tip
de dată abstractă (şi mai precis a unei clase). De aceea el încorporează atât datele cât şi
acŃiunile care se efectuează asupra acestor date. Datele unui obiect pot fi numite atribute,
variabile de stare, variabile de exemplificare, câmpuri sau componente de date. AcŃiunile
sunt numite metode sau funcŃii de componente. Dar independent de terminologia folosită
pentru date şi acŃiuni, ambele sunt prezente în obiecte ca parteneri egali. Similar, în toate
tehnicile orientate obiect, datele şi acŃiunile sunt considerate de aceeaşi importanŃă, nici una
neavând prioritate asupra celeilalte.
Nu este eronat să declarăm că datele şi acŃiunile se consideră simultan în tehnicile
paradigmei orientate obiect. Din moment ce asupra îmbunătăŃirii treptate este clar că sunt
momente când datele trebuie să fie în prim plan şi momente când acŃiunile sunt mai
importante. Oricum, datelor şi acŃiunilor li se acordă egală importanŃă în timpul fazelor
paradigmei orientate obiect.
Multe motive sunt date în capitolele anterioare arătând superioritatea paradigmei
orientate obiect faŃă de paradigma structurată. La baza tuturor acestor motive stă faptul că un
obiect bine proiectat înseamnă un obiect cu înaltă coeziune şi joasă asociere modelează toate
aspectele unei entităŃi fizice. Detaliile asupra implementării sunt ascunse: singura comunicaŃie
cu obiectul este prin mesajele trimise acestuia. Ca rezultat, obiectele sunt în mod esenŃial
unităŃi independente cu interfaŃă bine definită. Deci, sunt uşor şi sigur de păstrat, şansa unei
greşeli regresive este redusă. Mai departe, obiectele se pot refolosi şi această refolosire este
legată de proprietatea de moştenire. Întorcându-ne la dezvoltarea utilizând obiecte este mai
sigur să construieşti un produs la scară mare combinând aceste blocuri fundamentale de
construcŃie software decât să foloseşti o paradigmă structurată.
Toate aceste aspecte ale superiorităŃii paradigmei orientate obiect ridică o întrebare:
dacă paradigma structurată este atât de inferioară faŃă de paradigma orientată obiect , de ce a
avut atâta succes? ExplicaŃia poate fi că paradigma structurată a fost adoptată într-un moment
când ingineria software nu era larg practicată. În schimb, software-ul era simplu “scris”.
Pentru manageri cel mai important lucru este ca programatorii să separe liniile de
cod. S-a plătit ceva mai mult decât vorbe goale pentru cererile şi specificaŃia (analiza
sistemelor) produsului, iar designul nu a fost aproape niciodată executat. Modelul
“construieşte-şi-repară” a fost tipic pentru tehnicile din anii ’70. Astfel, folosirea paradigmei
structurate a expus pentru prima dată majoritatea dezvoltătorilor software la tehnici metodice.
Aceasta conduce la o altă întrebare: cum ştim că paradigma orientată obiect este
superioară tuturor tehnicilor de azi? Nu există date disponibile care să dovedească fără
putinŃă de tăgadă că tehnologia orientată obiect este mai bună decât orice există azi, obŃinerea
unor astfel de date fiind şi greu de imaginat. Cel mai bun lucru pe care-l putem face este să ne
184
Modelul orientat pe obiect
bazăm pe experienŃele organizaŃiilor care au adoptat deja paradigma orientată obiect. Deşi nu
toate rapoartele sunt favorabile, majoritatea atesta că folosirea paradigmei orientate obiect
este o decizie înŃeleaptă.
O ultimă întrebare: nu este posibil ca într-o zi să existe ceva mai bun decât
paradigma orientată obiect? Chiar cei mai mari susŃinători nu pretind că aceasta este ultimul
răspuns la toate problemele ingineriei software. Mai departe, inginerii software de azi caută
următoarea realizare majoră. Oricum, există puŃine domenii ale străduinŃei umane în care
tehnicile trecutului sunt superioare oricărui lucru care este pus azi înainte. Tehnicile din ziua
de azi, cum ar fi paradigma orientată obiect vor fi probabil super depăşite de tehnicile
viitorului. LecŃia importantă bazată pe cunoştinŃele actuale este că tehnicile orientate obiect
par să fie cele mai bune.
5.2. Modelul orientat pe obiect

ExperienŃa cu paradigma obiectuală a arătat că nevoile de interacŃiune între faze sau
porŃiuni de faze ale procesului, par să fie mai specifice celei obiectuale decât celei structurate.
Acest model este iterativ, încorporat prin paralelism şi suportă o dezvoltare
incrementată. Dezavantajul major îl constituie faptul că ar putea fi prost interpretat ca o
simplă încercare de a-l face mai performant decât este necesar. O cale eficientă de a produce,
are ca obiectiv general un proces linear ca şi modelul prototipului rapid, dar a aprecia că
realitatea paradigmei obiectuale este frecventă şi necesară. S-ar putea credea că această
problemă este o consecinŃă a noutăŃii aduse de paradigma obiectuală. Ca profesionişti de soft,
se cere multă experienŃă cu analiza obiectuală şi proiectarea obiectuală. Următorul pas
important a fost modelul prototipului rapid a cărui scop a fost reducerea nevoii de iteraŃii, a
fost urmat de modelul spirală care reflectă o apropiere iterativă faŃă de softul de dezvoltare şi
menŃinere. În plus, a fost arătat ca “backtack”-ul este un aspect intrinsec pentru analiza
obiectuală a tehnicii Coad-Yourdon şi este posibil ca rezultate similare să fie obŃinute printr-o
altă tehnică obiectuală. Cu alte cuvinte iteraŃiile reprezintă o proprietate intrinsecă a
produselor soft în general şi a paradigmei obiectuale în particular.
5.3. Modelarea use-case

Un use-case descrie funcŃionalitatea produsului ce urmează a fi construit. El oferă o
descriere generică a întregii funcŃionalităŃi, scenariile sunt priorităŃile unui use-case, la fel
cum obiectele sunt priorităŃile unei clase. Un use-case este preocupat de interacŃiunea globală
între clasele produsului software şi actorii (utilizatorii) produsului. Un scenariu este un set
particular de interacŃiuni între obiecte specifice şi utilizatori.
5.4. Modelarea clasei

În acest pas, clasele şi atributele lor sunt extrase şi reprezentate folosind o diagramă
relaŃie-entitate. Numai atributele unei clase sunt determinate, nu şi metodele; ultimele sunt
asignate claselor în timpul fazei de design orientat obiect (DOO).
O caracteristică a întregii paradigme orientate obiect este aceea că paşi diferiŃi sunt rar
uşor de realizat. Din fericire, beneficiile rezultate din folosirea obiectelor face ca efortul să
merite. N-ar trebui să fie deci o surpriză că prima parte a modelării clasei, adică extragerea
clasei şi a atributelor lor este greu de obŃinut corect de la început.
185
O metodă de determinare a claselor este deducerea lor din use-case. Aceasta înseamnă
că dezvoltătorii studiază cu atenŃie toate scenariile obişnuite şi neobişnuite şi identifică
alineatele care joacă un rol în use-case. Aşa cum vom vedea, aceste clase candidate sunt foarte
apropiate de clasele actuale extrase din modelarea clasei.
5.4.1. Extragerea substantivului

Pentru dezvoltătorii fără experienŃă domeniului, o bună soluŃie pentru a opera este
folosirea următorului proces în 3 etape pentru a extrage clasele candidate şi a îmbunătăŃi
soluŃia [4].
Etapa 1: Definirea concisă a problemei. Definirea produsului să se facă pe cât de scurt
şi concis posibil, preferabil într-o singură propoziŃie.
Etapa 2: Strategia neformală. Pentru a veni cu o soluŃie în rezolvarea problemei cu
strategia neformală, trebuie luate în considerare constrângerile. Strategia neformală poate fi
exprimată acum, preferabil într-un singur paragraf.
Etapa 3: Formalizarea strategiei. Se identifică substantivele din strategia neformală
(excluzând cele care se află la marginea problemei), apoi se folosesc ca şi clase candidate.
Strategia neformală este reprodusă acum cu substantivele identificate, tipărite în mai multe
forme.
5.5. Metodologia OMT (Object Modeling Tehnique)

OMT -ul este o tehnică de dezvoltare a softului bazată pe modele ca abstracŃii ale
problemelor lumii reale, menite să faciliteze aspectele importante ale problemei şi să omită
pe cele irelevante. El are trei aspecte importante şi anume: abstractizarea realităŃii, deci pentru
aceeaşi problemă se pot crea mai multe modele care să faciliteze diferite aspecte, scopul
modelului este facilitarea a ceva cunoscut şi comunicarea, deci modelul trebuie înŃeles de toŃi
membrii echipei de analiză-proiectare, de asemenea să fie înŃeles şi validat de utilizator.
În prezent s-au cristalizat două tipuri de metode ce se utilizează în analiză şi
proiectarea sistemelor informatice: metodele tradiŃionale (structurate) orientate pe date sau
funcŃii şi metodele orientate obiect. Comparativ cu cele tradiŃionale, abordarea orientată
obiect mută centrul de greutate al soluŃionării problemei în faza de analiză, fapt ce va
compensa cu minim de efort faza de implementare. Buna înŃelegere a cerinŃelor problemelor
reale va duce la construirea unui model fiabil, adaptabil, care suportă uşor modificările.
5.5.1. Concepte de bază

ConstrucŃia de bază în abordarea orientată obiect este obiectul, ce combină structura
datelor şi comportamentul într-o singură entitate.
Obiectul este o entitate a lumii reale asupra căreia se poate întreprinde o acŃiune sau
care poate întreprinde o acŃiune.
Obiectul este caracterizat prin: stare, comportament şi identitate [4].
Deci un obiect are două componente:
• starea informaŃională
• comportamentul sau operaŃiile ce acŃionează asupra structuri
Obiectele pot fi concrete, ce există în mod fizic şi conceptuale (o idee, o lege, etc.).
Comportamentul obiectelor poate fi declanşat de stimuli externi sau evenimente,
exemplu: eliberarea unei chitanŃe sau repară un automobil. Fiecare obiect conŃine informaŃii
individuale (date) ce trebuie să fie accesate sau modificate prin intermediul mulŃimii de
186
Metodologia OMT (Object Modeling Tehnique)
operaŃii ce definesc comportamentul obiectului respectiv. Singura parte vizibilă a unui obiect
este constituită din funcŃiile (operaŃiile) obiectului şi e numită interfaŃă.
Orice obiect are atribute şi operaŃii; atributele descriu un obiect şi sunt valori ale
datelor, iar funcŃiile (operaŃiile) definesc comportamentul obiectului. Un model de obiect este
format dintr-un număr de obiecte ce comunică între ele. Dintre acestea unele au caracteristici
comune şi pentru a păstra legătura semantică, ele sunt grupate în clase de obiecte. O clasă de
obiecte este o abstracŃie ce descrie toate caracteristicile comune ale unui grup de obiecte şi
care permite crearea de noi obiecte. Deci, descrie o mulŃime de obiecte cu atribute similare,
operaŃii similare, aceeaşi semantică şi aceeaşi relaŃie cu alte obiecte.
Evident, orice obiect face parte dintr-o clasă şi este considerat, în momentul în care
vrem să-l precizăm sau referim, ca o instanŃă a acelei clase. Fiecare instanŃă are o identitate
unică, diferenŃiind-se de alte instanŃe create pornind de la aceeaşi clasă. Dacă o instanŃă
trebuie să execute o operaŃie, selectarea operaŃiei are loc în clasa asociată instanŃei.
Implementarea unei operaŃii la un moment dat se numeşte metodă, deci, pentru o
operaŃie pot fi mai multe metode din care un obiect va selecta ce metodă vrea să execute într-o
situaŃie particulară. În metodele de obiecte ale unei aplicaŃii toate informaŃiile sunt memorate
de obiectele sale şi aceste informaŃii pot fi manipulate numai când obiectele execută operaŃii.
În obiectele/clasele de obiecte sunt ascunse atât structura cât şi implementarea
operaŃiilor prin procesul de încapsulare. La orientarea obiect construirea claselor are
caracteristicile comune ale obiectelor sau claselor de obiecte, respectiv al superclaselor sau
claselor abstracte, prin generalizare şi/sau agregare.
Similitudinile sau caracteristicile comune pot fi apoi moştenite de clasele sau obiectele
iniŃiale şi pot fi partajate între anumite clase, obŃinându-se astfel o ierarhie de moştenire în
care clasele generalizate se găsesc la nivelele superioare, iar clasele ce specializează o clasă
existentă sunt la nivelele inferioare.
Ierarhia de moştenire poate avea mai multe nivele şi poate conŃine clase concrete,
definite pentru a crea instanŃe şi clase abstracte ce nu au instanŃe, dar sunt constituite pentru a
asigura moştenirea. În orientarea obiect prin polimorfism se înŃelege faptul că o operaŃie poate
fi implementată diferit în clase diferite sau ca un atribut şi are sensuri diferite pentru clase
diferite.
Majoritatea metodelor orientate obiect utilizează reguli sau operaŃii semantice cum
sunt: generalizarea/specializarea, agregarea/descompunerea, combinate cu moştenirea şi
încapsularea.
OMT -ul propune trei tipuri de modele pentru trei scopuri diferite şi anume, modelele
care pot fi obiecte, fie interacŃiuni, fie transformări, respectiv: model obiectual, model
dinamic şi model funcŃional, conform figurii [44]:
MODEL OBIECTUAL
(obiect, lucruri)
MODEL DINAMIC MODEL FUNCłIONAL

(interacŃiuni) (transformări)
Figura 5.1 Tipuri de modele utilizate de OMT

Cele trei tipuri de modele sunt de fapt proiecŃii ale aceleiaşi informaŃii, fiecare
modelând un aspect al său şi în acelaşi timp cele trei modele sunt strâns legate între ele.
ImportanŃa relativă celor trei modele depinde de tipul aplicaŃiei ce se va proiecta.
Modelul obiectual este descrierea structurii statice a obiectului, claselor de obiecte, a
operaŃiilor şi atributelor, precum şi a legăturilor/relaŃiilor dintre ele.
187
Modelul dinamic, descrie interacŃiunea dintre obiecte şi este focalizat pe aspecte ce

schimbă în timp deoarece orice obiect are un ciclu de viaŃă cu un punct de pornire şi unul de
sfârşit. El descrie acest ciclu de viaŃă, adică ce este de-a lungul său şi cum este influenŃat
obiectul.
Modelul funcŃional arată transformările valorilor datelor, precizând sursa lor,
transformările lor şi destinaŃia lor.
Fiecare model în OMT se reprezintă cu diagrame, iar modalităŃile de reprezentare sunt [4]:
• la modelul obiect avem: CAD (Class Asssociation Diagram) sau DAC
(Diagrama de asocierea a claselor)
• la modelul dinamic avem: ETD (Event Trace Diagram) sau DTE (Diagramă de
trasare a evenimentelor)
• la modelul funcŃional avem:
o DFD (Data Flow Diagram) sau DFD (Diagrama fluxurilor de date)
o CCD (Class Comunication Diagram) sau DCC (Diagramă de
comunicare clase)
o MGD (Message Generalization Diagram) sau DGM (Diagrama de
generalizare a mesajelor)
5.5.2. Etape şi activităŃi

Flexibilitatea modelelor orientate obiect permite lucru într-un ciclu de viaŃă în spirală,
acest ciclu de viaŃă presupune faptul că doar o parte a modelului trebuie să fie gata înainte de
trecerea la faza următoare. Etapele ciclului de realizare rămânând aceleaşi în abordarea
orientată obiect şi sunt [30]:
1. Analiza, care are drept obiectiv modelarea problemei din lumea reală sau definirea
Domeniului aplicaŃiei.
2. Proiectarea de sistem, ce împarte modelul anterior în părŃi mai mici, mai uşor de
înŃeles şi construieşte arhitectura sistemului prin identificarea subsistemelor şi
alocarea lor pe hardul sistemului. Această etapă porneşte de la Domeniul aplicaŃiei
şi ia în considerare conceptele de implementare, adică optimizează, rafinează şi
extinde cele trei modele până la nivel de detaliu, care să permită implementarea.
Deci, analiza descrie probleme şi proiectarea dă soluŃii de rezolvare. Rezultatul
acestei etape este arhitectura de bază a sistemului şi adoptarea deciziilor privind
strategia la nivel global.
3. Proiectarea obiectuală, are drept scop alegerea modelului de implementare
pentru fiecare clasă, proiectându-se algoritmii şi se implementează asocierile. Se
realizează gruparea claselor în superclase, pentru uşurarea implementării şi pentru
îmbunătăŃirea performanŃelor. Aici se obŃine modelul obiectual detaliat, modelul
dinamic detaliat şi modelul funcŃional detaliat.
4. Implementarea presupune codificarea într-un limbaj de programare, iar clasele se
implementează în mod real într-un limbaj orientat obiect, acestea vor fi compilate,
testate şi combinate în programe executabile.
5.5.2.1. Etapa de analiză

Scopul acesteia este de a înŃelegere a problemei şi a domeniului aplicaŃiei, pentru
proiectarea corectă a ei, pornind de la cerinŃele exprimate de utilizator. Modelul de analiză
serveşte la clarificarea cerinŃelor, realizarea unei baze de înŃelegere între beneficiar şi
proiectant, reprezentând cadrul pentru proiectarea ulterioară şi implementare.
188
Rezultatul etapei este definirea unui model precis, concis, inteligibil şi corect al viitorului
sistem. Acest model este compus din cele trei modele amintite anterior şi anume:
• modelul obiectual ce surprinde aspecte statice
• modelul dinamic
• modelul funcŃional
Fazele analizei sunt [44]:
1. Analiza şi modelarea evenimentelor, cu activităŃile:
• scrierea declaraŃiei problemei
• analiza evenimentelor problemei
• modelarea evenimentelor
2. Construirea modelului de analiză, cu activităŃile:
• definirea modelului obiectual
• definirea modelului dinamic
• definirea modelului funcŃional
• reiterarea şi verificare
EsenŃial, relaŃiile existente între componentele modelului de analiză sunt redate în
figura 5.2.
5.5.2.2. Etapa de proiectarea a sistemului

În etapa precedentă se spune ce trebuie făcut şi nu cum, iar în această etapă se arată
cum şi pe parcursul ei se iau decizii referitoare la modul de rezolvare al problemei. Scopul ei
este transpunerea declaraŃiei problemei aşa cum a fost definită în etapa precedentă, bazată pe
divizarea în subsisteme precum şi decizii de implementare la nivel global. Rezultatul este un
concept de implementare care rafinează, optimizează şi extinde cele trei modele ale analizei
până la etapa de proiectare obiectuală care să permită implementarea propriu-zisă.
EnunŃ problemă
Scenarii de evenimente Modelul obiectual Modelul dinamic
DTE DAC DTS
Diagrame de trasare Diagrame de asociere Diagrame de

a evenimentelor a claselor tranziŃie a stărilor
Model de comunicare Modelul funcŃional

a claselor
DFD
DDC
Diagrama de comunicare Diagrama de flux
a claselor a datelor
Figura 5.2 Legăturile dintre componentele modelului analiză
189
Aceasta presupune două mari faze şi anume:

• construirea arhitecturii sistemului
• modelarea detaliilor subsistemelor
Prima fază dezvoltă clasele de bază, necesare la studierea funcŃionalităŃii sistemului şi
se iau decizii cu privire la modul de rezolvare a problemei stabilindu-se următoarele:
• configuraŃia soft şi hard necesară
• SGBD-ul necesar
• interfaŃa grafică cu utilizatorul
SoluŃia de sistem proiectată va include pe lângă clasele de bază şi clasele de interfeŃe
grafice şi clasele de acces la baza de date. Aceste trei tipuri de clase sunt grupate în sistem şi
deci scopul acestei prime faze este realizarea organizării generale a soluŃiei în componente
numite subsisteme, cu interfeŃele dintre ele.
A doua fază modelează în detaliu fiecare subsistem individual, accentul pus pe diferite
modele fiind diferit de la un tip de subsistem la altul, apoi se creează clasele numite
container, ce se organizează la nivel de sistem.
Fazele şi activităŃile acestei faze sunt [4]:
a. Construirea arhitecturii sistemului
a.1. Organizarea sistemului în subsisteme, cu activităŃile:
• importul în sistem a claselor de bază
• alegerea unei arhitecturi
• crearea unui model de comunicare între clase la nivel de proiect
• crearea subsistemelor pentru fiecare subiect
a.2. Definirea interfeŃelor
a.3. Identificarea obiectelor active concurente şi exclusive
a.4. Alocarea subsistemelor pe procesoare şi taskuri
a.5. Alegerea strategiei de bază pentru implementarea datelor memorate
a.6. Identificarea resurselor globale şi determinarea mecanismelor pentru
asigurarea accesului la date
a.7. Alegerea variantei de implementare a controlului
a.8. Stabilirea condiŃiilor limită
a.9. Stabilirea priorităŃilor
b. Modelarea detaliilor de subsistem
b.1. Definirea modelului de comunicare al claselor
b.2. Detalierea modelului obiectual
5.5.2.3. Etapa de proiectare obiectuală

Aceasta definitivează clasele şi asocierile, interfeŃele şi algoritmii utilizaŃi pentru
implementarea operaŃiilor.
Scopul său este de a adăuga la modelul obiectual rezultat anterior, detaliile de
implementare necesare fie pentru generarea automată de cod, fie pentru dezvoltarea ulterioară
fără generare automată.
Dacă se face implementarea cu generarea automată de cod, atunci modelul obiect este
singurul utilizat, iar una din activităŃile acestei etape este combinarea informaŃiilor tuturor
modelelor în modelul obiect.
Etapa identifică operaŃiile din etapa de analiză şi le transpune în algoritmi, iar clasele,
atributele şi asocierile sunt implementate în structuri de date specifice.
Modelele folosite sunt identice cu cele ale analizei, diferenŃa constând în faptul că
acum clasele sunt descrise din punct de vedere al implementării, anume:
190
• Modelul obiectelor – aici se rafinează prin introducerea de noi clase (cu

rezultatele intermediare ale calculului), noi operaŃii (ce s-au descoperit acum)
şi noi atribute.
• Modelul funcŃional – descrie operaŃiile pe care proiectantul trebuie să le
implementeze. Pe timpul proiectării el va alege algoritmii de implementare a
unei operaŃii şi va descompune operaŃiile mai complexe în operaŃii mai simple.
• Modelul dinamic – descrie felul în care sistemul răspunde stimulilor externi.
Deci, structura de control a programului derivă din acest model, iar fluxul de
control al programului trebuie realizat fie explicit, fie implicit.
Rezultatul îl constituie modelul obiect, dinamic şi funcŃional rafinat şi detaliat.
Fazele şi activităŃile acestei etape sunt:
a. Identificarea operaŃiilor pentru modelul obiectual pe baza celor două modele, cu:
a.1. Definirea unei operaŃii pentru fiecare eveniment din modelul dinamic;
a.2. Determinarea unei operaŃii pentru fiecare proces din modelul funcŃional;
b. Proiectarea algoritmilor de implementarea aplicaŃiilor, cu:
b.1. Alegerea algoritmilor ce minimizează costul operaŃiei de implementare;
b.2. Selectarea structurilor de date cele mai potrivite pentru algoritmii aleşi;
b.3. Definirea de noi clase şi noi operaŃii dacă este necesar;
b.4. Asocierea responsabilităŃilor pentru operaŃii ce sunt asociate la noi clase;
c. Optimizarea căilor de acces la date;
d. Implementarea controlului având în vedere soluŃia aleasă la proiectarea sistemului;
e. Restructurarea claselor pentru a creşte probabilitatea moştenirii;
f. Proiectarea implementării asocierilor, cu:
f.1. Analiza cursului asocierilor;
f.2. Stabilirea modului de implementare a asocierilor;
g. Gruparea claselor şi asocierilor în module.
Deciziile de proiectare luate aici trebuie susŃinute cu o documentaŃie adecvată, care ar
trebui să fie o extensie a cerinŃelor documentaŃiei realizate în etapa de analiză. Aceste decizii
trebuie documentate pornind de la modelul analiză, prin adăugarea detaliilor modelelor
obiectual, dinamic şi funcŃional. În acest scop se folosesc construcŃiile specifice
implementării: pointeri (la m obiecte), pseudocod structurat (m din) şi expresii funcŃionale (
m funcŃii).
5.5.3. ModalităŃi de reprezentare

Cele trei tipuri de modele recomandate de OMT, se folosesc din etapa de analiză
atunci când este realizată prim versiune a lor, apoi în etapa de proiectare (de sistem şi
obiectuală) când acele modele sunt detaliate şi completate până în implementarea de cod. Din
acest motiv însăşi reprezentările folosite la cele trei modele, deşi sunt aceleaşi, se detaliază şi
completează progresiv, pentru o mai bună scriere a aplicaŃiei şi a soluŃiei adoptate.
5.5.3.1. Modelul obiectual

Modelul obiectual se referă la structura statică a aplicaŃiei şi are ca scop evidenŃierea
obiectelor, claselor de obiecte, a atributelor şi operaŃiilor claselor, precum şi a asocierilor
dintre ele.
Aici se folosesc următoarele concepte [44]:
• obiect – concept, abstracŃie sau lucru bine determinat având o identitate
• clasă de obiecte – grup de obiecte cu aceleaşi atribute şi operaŃii semantice
191
5.5.3.2. Modelul dinamic

El descrie aspectele sistemului care se schimbă în timp, respectiv succesiunea
operaŃiilor. Acest model are ca scop evidenŃierea relaŃiilor temporale şi se folosesc
următoarele concepte:
Eveniment, care este ceva ce se întâmplă la un moment dat şi nu are durată
(instantaneu). El poate precede sau succede logic alt eveniment, iar structura claselor poate fi
ierarhică la fel ca cea a obiectelor. Evenimentul transmite informaŃii de la un obiect la altul,
valorile de date fiind atributele lui şi poate conŃine condiŃii.
Scenariu este o secvenŃă de evenimente care apar în timpul execuŃiei sistemului.
Acesta poate include toate evenimentele sistemului sau numai pe acelea generate sau
suportate de anumite obiecte din sistem.
Deoarece evenimentul transmite informaŃii de la un obiect la altul, scenariu trebuie să
identifice obiectele emiŃătoare şi pe cele receptoare pentru fiecare eveniment.
SecvenŃa de evenimente şi obiecte poate fi evidenŃiată prin Diagrama de Trasare a
Evenimentelor (DTE). Aceste diagrame se folosesc la analiza evenimentelor complexe din
declaraŃia problemei, mai exact pentru reprezentarea scenariilor indicând actorii (iniŃiatorii
evenimentelor), evenimentele şi obiectele. Modul de citire al DTE-ului este de sus în jos şi de
la stânga spre dreapta.
Deoarece un eveniment activează o operaŃie a obiectului receptor, evenimentul trebuie
să poarte acelaşi nume ca şi operaŃia căreia i se adresează, nume care trebuie să conŃină un
verb. La un eveniment al aplicaŃiei se poate modela un singur scenariu, numit scenariu
principal, iar dacă evenimentul aplicaŃiei este complex, pe lângă acesta se mai pot modela mai
multe scenarii alternative.
Alte elemente ale modelului dinamic sunt [44]:
• Starea – este o abstractizare a valorilor atributelor şi legăturilor unui obiect şi
specifică răspunsul obiectului la un eveniment de intrare. Răspunsul obiectului
la un eveniment poate include o acŃiune sau o schimbare a stării de către
obiect. Starea se păstrează nemodificată în intervalul dintre două evenimente
primite de un obiect. Starea are durată, care ocupă un interval de timp, deci
evenimentele reprezintă momente de timp, iar stările intervale de timp. Starea
este asociată unei valori a obiectului ce satisface o condiŃie.
• TranziŃie – reprezintă schimbarea stării cauzată de un eveniment.
• CondiŃie – este o funcŃie booleană pe valorile obiectului, validă pe o perioadă
de de timp. TranzacŃia condiŃionată apare numai dacă a apărut un eveniment şi
dacă condiŃia ce însoŃeşte tranziŃia este adevărată.
• OperaŃiile – sunt ataşate stărilor şi tranziŃiilor, descriind comportamentul unui
obiect ca răspuns la un eveniment. Acestea sunt executate ca răspuns la
tranziŃii sau stări. Ele pot fi de două tipuri şi anume: activităŃi sau acŃiuni.
• ActivităŃi – sunt operaŃii ce necesită timp pentru a se executa şi sunt asociate
unei stări care o controlează până când un eveniment o întrerupe şi se produce
o tranziŃie a stării.
• AcŃiune – este o operaŃie instantanee asociată unui eveniment, a cărei sursă
internă nu este interesantă, adică nu este modelată ca o activitate cu eveniment
de început, de sfârşit şi eventual eveniment intermediar.
Pe baza acestor elemente se realizează Digrama de TranziŃie a Stărilor (DTS),
pentru toate obiectele din sistem cu comportament dinamic important.
Modelul dinamic este o colecŃie de DTS-uri ce interacŃionează unele cu altele prin
evenimente partajate.
Modelul dinamic descrie structura de control a sistemului.
192
5.5.3.3. Modelul funcŃional

Acesta are ca scop descrierea structurii de calcul a sistemului evidenŃiind modul în
care sunt obŃinute ieşirile pe baza intrărilor şi altor valori intermediare. Grafic modelul
funcŃional este dat de Diagrama de Flux a Datelor (DFD).
Sunt utilizate conceptele [4] [10]:
• Proces – un proces transformă valorile datelor şi corespunde unei operaŃii din
clasele implicate. El poate fi simplu şi complex, arătând ce date de intrare sunt
transformate şi ce date de ieşire se obŃin.
• Fluxuri de date – caracterizează ieşirea unui obiect sau proces la intrarea unui
alt obiect sau proces, fluxul putând fi trimis în mai multe locuri.
• Flux de control – corespunde unui mesaj dintr-o diagramă de comunicare sau
unui eveniment într-un DFD.
• Actor – un obiect activ ce produce sau consumă date. Actorii sunt ataşaŃi la
intrări sau la ieşiri din DFD-uri şi sunt surse sau destinaŃii de date şi de aceea
se numesc terminatori.
• Depozit de date – este un obiect pasiv care memorează date pentru accesul
ulterior. Depozitele de date vor exista fizic ca fişiere sau baze de date.
Fluxurile de date sunt valori, iar fluxurile intermediare reprezintă valori intermediare
rezultate din calcule.
Atât actorii cât şi depozitele de date sunt obiecte cu comportament şi utilizare diferită.
DFD-urile folosesc următoarele simboluri:
Proces - este un proces de prelucrare ce are numele format dintr-un verb şi un

substantiv, ce identifică procesul;
Nume_flux - fluxul de date;
Nume_flux - flux de control;
Nume_actor - actor/terminator;
Nume_depozit - depozit de date cu nume unic.
Forma generală a unui DFD este în figura următore:

Proces_2
Proces_1 Flux de control 1
Flux_4
Flux_5
Flux_1 Flux_2 Depozit de date 1
Sursă DestinaŃie
Proces_3
Flux_3
Figura 5.3 Forma generală a unui DFD
DFD-urile evidenŃiază pe lângă fluxurile de date dintre terminatori, procese şi depozite

de date, precum şi fluxuri de control.
193
FuncŃiile de control în DFD sunt funcŃii booleene ce afectează execuŃia unui proces.
Procesele din DFD trebuie implementate ca operaŃii ale obiectelor.
OperaŃiile pot fi specificate prin [4] [21]:
• funcŃii matematice, ecuaŃii între intrări şi ieşiri
• tabele de corespondenŃă între intrări şi ieşiri
• tabele de decizie
• pseudocod
• limbaj natural structurat
Exemplu de DFD la o firmă pentru o comandă în figura următoare:
Furnizor_inexsistent Verifică_furnizor
Cod_furnizor
Firmă
Furnizor_existent
Cod_furnizor
Comandă
Date_furnizor externă
Furnizor
Inregistrare_furnizor Date_furnizor
Figura 5.4 Exemplu de DFD
Modelul funcŃional este format din DFD-uri, adică grafuri ale căror noduri sunt
procesele, iar arcele sunt fluxurile de date şi de control.
Între cele trei modele sunt următoarele relaŃii:
• Modelul static – descrie structura datelor pe care le operează modelul dinamic
şi funcŃional. OperaŃiile din modelul obiectual corespund evenimentelor din
modelul dinamic şi funcŃiilor din modelul funcŃional.
• Modelul dinamic – descrie structura de control şi evidenŃiază deciziile ce
cauzează acŃiuni, apelează funcŃii şi schimbă valorile obiectelor.
• Modelul funcŃional – descrie funcŃiile apelate de operaŃiile din modelul static
şi acŃiunile din modelul dinamic. El operează asupra valorilor atributelor din
modelul obiect şi evidenŃiază restricŃiile asupra acestora .
OMT -ul are avantajul că foloseşte notaŃii pentru modelare în întreg ciclu de viaŃă,
astfel încât nu este necesară o trecere abruptă la alte notaŃii sau interpretări ale semanticii în
etapele următoare ale proiectării, iar ca dezavantaj că nu oferă ghidare metodologică în
etapele timpurii ale procesului de dezvoltare.
5.6. Metodologia RUP (Rational Unified Process)

RUP reprezintă o metodologie, care permite unei echipe de dezvoltători, să aibă o
abordare disciplinată în alocarea sarcinilor şi responsabilităŃilor în cadrul unui proces de
dezvoltare a unui sistem informatic în limitele de timp şi de buget prestabilite. RUP este un
proces orientat pe produs şi este susŃinut de multe instrumente puse la dispoziŃie de Rational
Corp. RUP îmbunătăŃeşte productivitatea echipei, facilitând fiecărui dezvoltător accesul la o
194
Metodologia RUP (Rational Unified Process)
bază de cunoştinŃe cu linii directoare, şabloane şi instrumente care permit monitorizarea

tuturor activităŃilor critice care apar pe parcursul procesului de dezvoltare. RUP a fost
conceput special pentru a optimiza utilizarea UML-ului şi este un proces configurabil,
suportat în mare parte de instrumente care automatizează o bună parte a procesului. Metoda se
pretează atât echipelor de dezvoltare mici cât şi organizaŃiilor mari.
RUP este o metodă iterativă. Fiecare iteraŃie are unul sau mai multe obiective. În RUP
obiectivul este de a produce software funcŃional, care să aducă valoare adăugată şi să fie livrat
clientului. IteraŃiile sunt delimitate de termen limită (prezentate în figura 5.5 ca marcatori de
etapă). Fiecare facilitate trebuie realizată într-un anumit interval de timp.
Figura 5.5 Metoda RUP [44]

Dacă facilitatea respectivă nu este implementată în termenul alocat, ea este plasată
spre finalizare într-o altă iteraŃie, ori se renunŃă la implementarea ei. Nu este permisă
extinderea perioadei unei iteraŃii. RUP este o metodă incrementală şi iterativă, deoarece
fiecare iteraŃie adaugă valoare activităŃilor derulate anterior. Prin adăugări succesive se ajunge
la produsul dorit. Modelul iterativ de dezvoltare reduce riscul prin semnalizarea acestor
iteraŃii ca faze când modificările nu sunt costisitoare. Fiecare iteraŃie a RUP -ului se derulează
similar unui minimodel în cascadă. SecvenŃa de activităŃi derulată în cadrul minimodelului în
cascadă este posibil să nu fie liniară. De exemplu: se poate lucra le cerinŃe, apoi se trece la
analiză şi proiectare, se revine la cerinŃe, apoi se trece la testare, în funcŃie de activitatea care
trebuie completată.
RUP utilizează următoarele concepte cheie [37]:
• lucrător – rolul pe care-l joacă o persoană în cadrul proiectului (proiectant,
programator, tester etc.)
• activitate – unitate de lucru pe care lucrătorul o execută. O activitate ia de
obicei ore sau zile de efort (de exemplu redactarea unui caz de utilizare,
scrierea codului unei clase, reanalizarea proiectării sau testarea unui,
component etc.).
• flux de activităŃii – este o secvenŃă de activităŃi, care au drept rezultat
producerea artefactelor dorite (cerinŃe, proiectare, implementare, testare)
• iteraŃie – iteraŃia include fluxurile de activităŃi necesare producerii unei
versiuni de uz intern. Fiecare iteraŃie pune accent pe un subset de fluxuri de
activităŃi specifice fiecărei faze.
195
• faza – un set de una sau mai multe iteraŃii, care împreună satisfac cel puŃin un
criteriu ce trebuie evaluat prin raportare la marcatorul de etapă. Fazele sunt
similare fazelor modulului în cascadă exceptând activităŃile care pot fi
dezvoltate cu grade diferite pe fiecare fază.
• ciclu de dezvoltare – perioada de timp care include toate eforturile
direcŃionate în procedura şi lansarea unei versiuni a produsului pe piaŃă.
Aceasta reprezintă cea mai mare unitate de planificare.
RUP propune descompunerea ciclului de viaŃă al unui produs software în mai multe
cicluri, fiecare dintre aceste cicluri încheindu-se cu o aplicaŃie funcŃională. Un ciclu este
compus din 4 faze [37]:
• de iniŃiere
• de elaborare
• de construcŃie
• de tranziŃie
O fază poate fi descompusă la rândul ei în mai multe iteraŃii. O iteraŃie reprezintă de
fapt, o buclă de dezvoltare completă, care are drept rezultat lansarea internă sau externă a unui
produs care face parte din produsul final.
Figura 5.6 Ciclul RUP

Faza de iniŃiere implică analizarea cazului şi delimitarea scopului proiectului. În
această etapă sunt modelate, cazurile de utilizare, şi descrise cele mai importante dintre
acestea. Analiza cazului implică evaluarea riscurilor, citirile de evaluare a reuşitei sistemului,
resursele necesare precum şi realizarea unui plan în care sunt prevăzute date şi termene. Faza
se finalizează cu elaborarea unui document care prevede cerinŃele de bază ale proiectului,
funcŃiunile cheie şi constrângerile proiectului, un eventual model de afacere precum şi mai
multe cazuri de utilizare parŃiale.
În unele situaŃii etapa are unul sau mai multe prototipuri. Persoanele care vor folosi
produsul, cumpărătorul, dezvoltătorul şi managerii implicaŃi, vor avea o imagine introductivă
asupra a ceea ce presupune proiectul, vor înŃelege şi accepta ceea ce trebuie făcut ca urmare a
şedinŃelor comune de discuŃii, cât de mult timp va lua proiectul şi care va fi costul estimativ.
Cei care participă în această primă fază se asigură de faptul că cerinŃele şi priorităŃile sunt
înŃelese şi formulate corect de către toŃi care participă la proiect. Oricine poate să semnaleze
în această etapă riscuri potenŃiale pe care le sesizează, încercând luarea lor în calcul.
Faza de elaborare conduce la analizarea domeniului problemei, stabilirea unei
arhitecturi de bază, dezvoltarea planului proiectului şi eliminarea elementelor care comportă
cel mai ridicat risc. La sfârşitul etapei se poate considera că partea dificilă a procesului de
concepere este încheiată. Depăşirea acestei etape, presupune trecerea de la operaŃiile lipsite de
risc la cele care implică un cost ridicat, în cazul în care ar trebui efectuate modificări. În
196
Metodologia RUP (Rational Unified Process)
această etapă este esenŃial ca arhitectura concepută să fie suficient de stabilă, astfel încât să
permită eventualele extinderi ulterioare. În cadrul etapei se construiesc unul sau mai multe
prototipuri funcŃionale care să răspundă cerinŃelor critice ale proiectului. Acestea nu
reprezintă prototipul final – obŃinerea lui necesitând noi iteraŃii. Ca principale rezultate ale
acestei etape avem: un model de caz de utilizare dezvoltat cel puŃin 80%, sunt evidenŃiate noi
facilităŃi care nu sunt asociate cu cazul de utilizare specific, se obŃine o descriere a arhitecturii
software şi o actualizare a planurilor şi documentelor obŃinute în prima fază.
De asemenea, se documentează prototipul funcŃional. Se va şti cu exactitate ce se va
construi (arhitectură stabilă), iar utilizatorii finali vor fi de acord că aceasta va răspunde
cerinŃelor lor. Sunt descrise scenariile cele mai importante pe care produsul trebuie să le
suporte pentru a fi acceptat şi s-a demonstrat prin intermediul prototipurilor succesive, că sunt
întrunite condiŃiile de succes.
Faza de construcŃie presupune dezvoltarea celorlalte componente şi funcŃiuni integrate
în produs, precum şi testarea intensivă a aplicaŃiei. În această fază se construieşte efectiv
sistemul iar accentul se pune pe gestionarea resurselor, alocarea eficientă a acestora şi
diminuarea costurilor, respectarea termenelor, bugetelor şi standardelor de calitate.
Proiectele foarte mari pot fi descompuse în mai multe fluxuri de iteraŃii paralele, prin
aceasta obŃinându-se o importantă accelerare a procesului de dezvoltare al versiunilor
funcŃionale. Faza se concretizează în: modele complete ale sistemului, produsul software
propriu-zis într-o versiune alfa, manualele de utilizare. Utilizatorii trebuie să fie în măsură să
utilizeze şi să testeze produsul, iar din punct de vedere al bugetului ar trebui să avem
certitudinea că acesta nu va fi depăşit.
Metoda RUP utilizează nouă procese, clasificate drept procese de bază şi procese
suport. Figura 5.7 prezintă procesele în raport cu fazele RUP.
Figura 5.7 Procesele metodei RUP [37]

Faza de tranziŃie este cea în care se realizează efectiv transferul produsului software
către utilizatorul final. Odată lansată această versiune finală, noile versiuni reprezintă de fapt
fie îmbunătăŃirea algoritmilor, fie rezolvarea unor probleme care au apărut sau a căror
rezolvare fusese amânată. În această etapă are loc testarea cu versiuni „beta”, operarea
197
paralelă cu vechiul sistem informatic, conversia bazelor de date, training-ul utilizatorilor, al

echipelor de vânzări, de marketing şi de distribuire.
La finalul acestei etape se obŃine sistemul în starea finală. Utilizatorii au acceptat
produsul şi sunt în măsură să-l utilizeze. Utilizatorii sunt instruiŃi cum să facă trecerea de la
vechiul sistem la cel nou. Sistemul este acceptat din perspectiva criteriilor pe care trebuie să le
îndeplinească.
Procesul de modelare a afacerii presupune înŃelegerea de către echipa de analiză şi
proiectare a modului de derulare a afacerii. În acest proces se documentează, prin intermediul
cazurilor de utilizare, procesele de afacere. Există situaŃii, în care procesul de modelare a
afacerii nu este implementat, urmând ca această înŃelegere să aibă loc în cadrul proceselor
următoare. Procesul de identificare a cerinŃelor afacerii presupune înŃelegerea detaliată a
modului de derulare a afacerii. În cadrul acestui proces se va identifica mulŃimea cerinŃelor
potenŃiale. Din această mulŃime se vor selecta cerinŃele funcŃionale şi cele suplimentare.
Stabilirea cerinŃelor implică o strânsă comunicare între echipa de dezvoltare şi utilizatorii
finali ai aplicaŃiei. Principala barieră care trebuie depăşită într-o asemenea situaŃie, este
comunicarea între cele două echipe. Limbajul de specialitate al utilizatorului s-ar putea să nu
fie cunoscut de către echipa de dezvoltători.
Procesul de analiză şi proiectare presupune analizarea modului în care pot fi transpuse
în termeni tehnologici funcŃionalităŃile identificate. Acest proces presupune utilizarea unei
metodologii de proiectare. Procesul se finalizează cu obŃinerea unei arhitecturi şi a
documentaŃiei de proiectare.
Procesul de implementare constă în scrierea efectivă a codului. În cadrul acestui
proces se alege limbajul de programare, se stabilesc şabloanele privitoare la stilul de
programare, se stabilesc normele de calitate etc.
Procesul de testare implică verificarea tuturor componentelor dezvoltate în
conformitate cu specificaŃiile clientului. Testarea se realizează atât în faza de dezvoltare, cât
mai ales în momentul implementării.
Procesul de livrare presupune construirea versiunii executabile, configurarea staŃiilor,
instalarea produsului software pe staŃii, distribuirea produsului, instruirea utilizatorilor cu
privire la utilizarea sa.
Procesul de gestionare a modificărilor şi configuraŃiei presupune monitorizarea
versiunilor lansate, a actualizărilor simultane, comunicarea între dezvoltători cu privire la
modificările intervenite şi care ar putea să afecteze activitatea altora. Procesul de gestionare a
proiectului implică evaluarea resurselor, a obiectivelor a termenelor şi alocarea acestora astfel
încât să se asigure succesul proiectului. Succesul unui proiect software poate fi evaluat conform
gradului de utilizare a unui sistem, din perspectiva funcŃiunilor pe care trebuia să le
implementeze. Procesul de gestionare a impactului mediului presupune stabilirea cu exactitate a
activităŃilor şi liniilor directoare din cadrul proiectului. În cadrul acestui proces, se furnizează o
procedură, care descrie pas cu pas cum se implementează produsul într-o organizaŃie.
Conform lui Kruchten (2001) RUP are următoarele caracteristici:
• dezvoltarea interactivă a produsului soft – presupune dezvoltarea în
incrementări scurte ale unor iteraŃii succesive. Aceasta asigură o detectare
timpurie a riscurilor şi o adresare adecvată a acestora.
• gestionarea cerinŃelor – este un proces continuu de identificare a cerinŃelor
unui sistem, care evoluează de-a lungul timpului, cât şi a acelora care au cel mai
mare impact asupra sistemului. Gestionarea acestor cerinŃe implică o manieră
disciplinată de evaluare, asociere de priorităŃi şi monitorizare. Comunicarea are
şanse mai mari atunci, când are la bază un set de cerinŃe bine definit.
• foloseşte arhitecturi bazate pe componente – un sistem care are la bază o
arhitectură pe componente este mult mai flexibil, permiŃând extensibilitatea
198
Metoda MDA (Model Driven Architecture)
ulterioară a respectivei aplicaŃii. Componentele respective pot fi reproiectate

sau poate fi extinsă funcŃionalitatea, fără ca prin aceasta să se pericliteze
evoluŃia pe ansamblu a sistemului.
• utilizează instrumente vizuale în sprijinul modelării, prin aceasta ajutând
înŃelegerea sistemelor complexe – prin utilizarea modelelor UML
complexitatea unui sistem poate fi gestionată între mai multe echipe de
dezvoltători
• verifică în permanenŃă calitatea produsului soft – aceasta reprezintă o
preocupare constantă care se derulează la nivelul fiecărei iteraŃii. Printr-o
asemenea abordare defectele sunt din timp descoperite şi costul rectificării
erorilor se diminuează.
• controlează schimbările aduse în produsul soft dezvoltat – gestiunea
acestor schimbări reprezentând un factor cheie al succesului dezvoltării unui
sistem informatic fiabil.
5.7. Metoda MDA (Model Driven Architecture)

MDA reprezintă o modalitate de proiectare pentru dezvoltarea unui produs software.
Această idee a fost lansată în 2001 de gruparea OMG. MDA a început odată cu bine
cunoscuta idee de a separa specificaŃiile unui sistem de detaliile de implementare a acestuia pe
o anumită platformă de dezvoltare [20].
MDA ne propune o soluŃie pentru:
• specificarea unui sistem independent de platformă
• specificarea platformei
• alegerea unei platforme particulare pentru sistemul software
• transformarea specificaŃiilor pentru un anumit sistem în unele pentru o
platformă particulară
Figura următoare ilustrează folosirea împreună a standardelor OMG în arhitectura
MDA:
Figura 5.8 Arhitectura MDA [20]
199
MDA separă modelele unui sistem şi aduce o structură consistentă acestor modele. În
continuare vom prezenta cum se leagă între ele modelele MDA si cum sunt folosite.
5.7.1. CIM (Computation Independent Model)

CerinŃele pentru un sistem sunt modelate într-un model CIM, care descrie situaŃia în
care sistemul va fi folosit. Acest model mai este cunoscut şi sub numele de model domeniu
sau model business. Acest model s-ar putea să ascundă aproape toată informaŃia despre
procesarea automată a datelor acelui sistem. De obicei, acest model este independent de felul
în care sistemul este implementat.
Un CIM este un model care ne arată sistemul în mediul în care va opera şi acest lucru
ajută deoarece prezintă exact ce se aşteaptă de la sistem. Este folositor nu numai pentru a
înŃelege o problemă, ci este o sursă ce poate fi folosită şi în alte modele. Într-o specificaŃie
MDA a unui sistem CIM, cerinŃele trebuie să ne ducă la PIM şi PSM ce le implementează şi
vice-versa. Un CIM poate fi alcătuit din două modele UML. Unul poate oferi mai multe
detalii decât celălalt sau să se axeze pe un detaliu particular.
5.7.2. PIM (Platform Independent Model)

PIM oferă specificaŃii formale ale structurii şi funcŃionării sistemului care
abstractizează detaliile tehnice. PIM descrie un sistem, dar nu arată detalii ale utilizării
acestuia pe o anumită platformă. Un PIM se poate potrivi unui stil particular de arhitectură a
unui sistem sau a mai multor sisteme.
5.7.3. PSM (Platform Specific Model)

Modelul specific platformei produs de transformare este un model al aceluiaşi sistem
ca si cel specificat de PIM. Totodată, el specifică cum sistemul este folosit pe platforma
aleasă. Un PSM poate oferi mai multe sau mai puŃine detalii, în funcŃie de scopul său. Un
PSM va fi de fapt o implementare ce va oferi o varietate de diferite informaŃii, ce pot include
cod, legături cu alte programe, descriptori de deployment şi alte forme de configurări
specifice.
5.7.4. Transformarea modelului

Transformarea modelului reprezintă procesul de convertire a unui model în alt model
pentru acelaşi sistem. PIM -ul şi alte informaŃii sunt combinate de o transformare pentru a
produce un PSM. Totodată figura este generică. Există multe căi prin care o astfel de
transformare poate fi făcută. Oricum este făcută, ea produce dintr-un model independent de
platforma unul specific [20].
Există un suport pentru transformarea modelului, transformările pot folosi un amestec
de transformări manuale şi automate. Există diferite moduri de a pune într-un model
informaŃia necesară pentru a transforma un PIM în PSM.
5.7.4.1. Transformarea manuală

Pentru a putea face o astfel de transformare trebuie luate în primul rând decizii de
design. Aceste decizii pot fi luate fie in timpul procesului de dezvoltare a designului care se
conformează cerinŃelor asupra implementării. Totuşi, acest proces manual nu diferă foarte
mult de modul cum se făcea înainte designul. MDA a adus o singură valoare şi anume
distincŃia explicită între PIM şi PSM.
200
Metoda MDD (Model Driven Development)
5.7.4.2. Transformarea folosind un profil

Un PIM trebuie pregătit folosind un profil UML independent de platformă. Acest
model poate fi transformat într-un PSM folosind un al doilea profil UML, care trebuie sa fie
specific platformei. Transformarea poate duce la marcarea PIM -ului folosind un mark oferit
de profilul platformei specifice.
5.7.4.3. Transformarea automată

Există cazuri în care un PIM poate oferi toată informaŃia necesară implementării şi în
acest caz nu mai este nevoie să folosim date din profile adiŃionale pentru a putea genera cod.
Toate deciziile arhitecturale sunt făcute odată pentru un număr de proiecte, toate construind
sisteme similare.
Aceste decizii sunt implementate în tool-uri, librării sau generatoare de cod. În acest
caz, nu este nevoie să adăugăm informaŃii PIM -ului în afară de cele deja disponibile tool-ului
de transformare. Acesta interpretează modelul direct sau îl transformă direct în cod. Astfel,
pentru o aplicaŃie, programatorul are nevoie doar de PIM şi codul va fi generat automat.
5.7.5. Tool-uri pentru MDA

Un tool pentru MDA este un tool folosit pentru dezvoltarea, interpretarea, compararea,
verificarea, transformarea modelelor sau metamodelelor. Acesta poate fi unul din următoarele
tipuri [20]:
• Tool pentru creare – un tool folosit pentru crearea modelelor iniŃiale.
• Tool pentru analiză – un tool folosit pentru a verifica inconsistenŃa, condiŃiile
de eroare sau avertisment. Este totodată folosit pentru a calcula metrici pentru
model.
• Tool pentru compoziŃie – un tool folosit pentru a compune modele sursă, care
să se conformeze aceluiaşi metamodel.
• Tool de simulare – un tool folosit pentru a simula execuŃia unui sistem
reprezentat de un anumit model.
• Tool de management a metadatelor – un tool folosit pentru a se ocupa de
relaŃiile generale între diferite modele, incluzând metadata fiecărui model.
Implementări ale specificaŃiilor OMG putem găsi la companiile private sau soluŃii
open-source. Foarte multe din standardele de modelare pot fi găsite în Eclipse Modeling
Framework (EMF) sau Graphical Modeling Framework (GMF).
Microsoft propune tool-uri DSL. Un alt proiect open-source care ne propune un
framework extensibil pentru generarea codului folosind orice tehnologie sau platformă este
AndroMDA. Pe lângă acestea există o mulŃime de tool-uri UML ce pot fi folosite pentru
generarea codului.
5.8. Metoda MDD (Model Driven Development)

MDD este o nouă metodă de proiectare a sistemelor informatice aplicabilă în cadrul
metodologiei MDA. Prin intermediul acestei metode se construieşte un ansamblu de modele
ale sistemului de analizat cât şi ale noului sistem, pe baza cărora se generează alte modele sau
codul sursă ale sistemului.
În principiu, totul se centrează pe transformarea modelelor sistemului de realizat şi
generare de cod sursă. Această metodă necesită un mediu integrat de dezvoltare (IDE) care să
suporte: limbajul UML, şabloane, transformarea modelelor UML şi generare de cod sursă.
201
Rational Software Architect (RSA) este un astfel de instrument integrat de proiectare şi

dezvoltare de sisteme informatice.
Pentru această metodă este esenŃială modelarea primară a domeniului de afaceri
folosind limbajul UML. Transformarea automată a modelelor, sincronizare şi generare de cod,
este o trăsătură caracteristică acesteia prin care se realizează automatizarea procesului de
dezvoltare de aplicaŃii soft.
În urma transformărilor aplicate în diferite faze ale procesului de dezvoltare de sisteme
informatice se pot genera: alte artefacte (modele) detaliate (un sistem informatic presupune
mai multe niveluri de abstractizare: analiză, proiectare, implementare; diferite părŃi
componente: interfeŃe, baze de date, logica aplicaŃiei; diferite activităŃi: modelare, testare,
realizare, etc.; iată de ce, prin trecerea de la analiză la proiectare, de exemplu, se transformă
modelul de analiză în model de proiectare), documentaŃia aferentă diferitelor modele (cum ar
fi instrumentul Rational Software Architect’s Report Generator sau IBM Rational SoDA –
IBM Rational Software Documentation Automation), modele de testare (aplicând JUnit),
construirea şi dezvoltarea de scripturi, aplicarea şabloanelor. Mai mult, deciziile privind
specificaŃiile de implementare sunt incluse direct în transformările modelelor.
Metoda MDD se fundamentează pe abstractizare, care permite realizarea vederii
conceptuale a sistemului informatic, centrarea pe funcŃiunile sistemului fără specificaŃii de
implementare. Este recunoscut faptul că, este mai rapidă crearea modelelor unui sistem
informatic decât scrierea de cod-sursă, motiv pentru care se agreează această metodă care
permite lucrul la un nivel ridicat de abstractizare, permite includerea specificaŃiilor de
proiectare în modele, urmat de generarea codului sursă prin aplicarea de transformări
automate între modele. Modelul sistemului informatic sunt independente de orice detalii de
platformă de implementare sau tehnologii IT dar permit transformări prin care se generează
artefacte ce conŃin aceste specificaŃii tehnologice.
O altă caracteristică de bază a acestei metode este aceea de a permite modelarea logică
a integrării aplicaŃiilor software, independent de tehnologiile IT folosite pentru implementarea
lor. Într-o astfel de situaŃie se procedează în felul următor: se aplică metode de transformare
inversă aplicŃie-model logic, acest model logic se integrează în modelul logic al noului sistem
informatic obŃinându-se o vedere consistentă a întregii soluŃii soft, după care se aplică o
transformare prin care se generează codul sursă de integrare pentru o platformă soft/hard
optimă.
Pornind de la delimitarea clară dintre modelele logice şi cele de implementare, se
poate vorbi de fapt, de o tehnică de modelare stratificată care permite obŃinerea modelului de
analiză, de proiectare şi de implementare.
Cele trei modele se definesc astfel [20]:
• modelul de analiză – conŃine cazurile de utilizare
• modelul de proiectare – include arhitectura sistemului realizat independent de
specificaŃii de implementare
• modelul de implementare – conŃine specificaŃiile de implementare
De precizat că nu este singura stratificare posibilă, pot exista de asemenea, modele ale
proceselor de afaceri, ale cerinŃelor, de proiectare de ansamblu, de proiectare detaliată, etc.
Ideea este că fiecare strat adaugă detalii soluŃiei soft de realizat.
Etapele de realizare a sistemelor informatice în cadrul metodei Model Driven
Development (MDD) sunt prezentate în continuare. Primele etape sunt de creare a arhitecturii
sistemului şi de definire a mediului de implementare(platforme soft/hard, tehnologii IT).
Pe baza arhitecturii sistemului informatic sunt identificate şabloanele de analiză ce se
pot aplica cât şi a modulelor de aplicaŃii dezvoltate în alte proiecte MDD. Pe baza acestora se
creează modelul de proiectare al sistemului şi modelul de implementare pe componente pe
202
Limbajul UML (Unified Modeling Language)
baza căruia se produc un număr de artefacte iniŃiale ce vor reprezenta scheme pentru
următoarele transformări MDD.
Se definesc instrumentele ce vor fi utilizate şi o planificare a întregului proiect de
dezvoltare a sistemului informatic. Sunt generate template-uri pe baza artefactelor obŃinute
anterior, care sunt testate, evaluate, sunt create module funcŃionale pentru care se furnizează şi
documentaŃia aferentă.
În acest moment se poate trece la dezvoltarea aplicaŃiilor precedată de instruirea în
prealabil a echipei de dezvoltare.
Vederea
Vederea logică
implementării
(cerinŃe
(programe)
funcŃionale)
Vederea cazurilor
de utilizare
(use case)
Vederea
operaŃională Vederea distribuirii
(procese de afaceri) (platforme hard/soft)
Figura 5.9 Perspectivele 4+1 ale arhitecturii sistemului informatic în cazul metodei MDD
Similar metodelor orientate obiect şi metoda MDD presupune proiectarea arhitecturii

sistemului informatic percepută în două stadii diferite: logică şi fizică [20].
Aşa cum arhitectura unui sistem, în mod tradiŃional, este definită prin 4+1 perspective
diferite (reprezentate prin vederea cazurilor de utilizare, situată central, vederea logică,
vederea implementării, a distribuirii şi a exploatării) şi metoda MDD se situează central
vederea cazurilor de utilizare alături de vederea implementării, ce corespunde structurării
programelor de formează sistemul în componente, vederea logică, ce descrie cerinŃele
funcŃionale ale sistemului, vederea distribuirii, ce defineşte aspectul spaŃial al sistemului
(echipamente hardware, noduri de reŃea) şi vederea operaŃională sau a proceselor, ce
corespunde structurii de exploatare a programelor şi componentelor executabile.
Prin vederea cazurilor de utilizare se realizează conexiunile utilizatori-servicii şi
servicii-tehnologii IT.
5.9. Limbajul UML (Unified Modeling Language)
5.9.1. ApariŃia şi evoluŃia limbajului

UML-ul este un limbaj standard pentru scrierea de schiŃe de soft. Scopul său este
vizualizarea, specificarea, construirea şi documentarea artefactelor unui sistem, un soft
intensiv orientat obiect.
El este nu numai un limbaj, este numai o parte a unei metode de dezvoltare soft. Cu
toate că UML-ul este independent de proces, în mod normal el ar trebui folosit în procesele
conduse de cazurile de utilizare, centrate pe arhitectura sistemului.
El este un limbaj de modelare şi nu o metodologie. Metodologia constă dintr-un limbaj
de modelare şi un proces de modelare. Limbajul de modelare este o notaŃie grafică folosită
203
pentru descrierea modelului, iar procesul este succesiunea de paşi ce trebuie făcuŃi pentru
realizarea efectivă a modelului.
UML-ul este un limbaj de vizualizare, specificare, construire şi documentare a
modelelor şi valoarea sa constă în [4] [10]:
• standardul său deschis
• are întreg ciclul de viaŃă al dezvoltării softului
• acoperă multe tipuri de aplicaŃii
• este bazat pe experienŃa celor ce l-au realizat
• este implementat de multe produse de tip CASE
El este un limbaj de modelare vizuală ce foloseşte notaŃii standard, deci UML -ul
surprinde şi descrie în limbaj grafic sistemul.
Modelarea vizuală are cinci principale caracteristici:
• descoperă procesele ce au loc în sistem, folosind analiza cazurilor de utilizare
(USE CASE)
• se constituie într-un bun mijloc de comunicare
• simplifică/reduce complexitatea sistemului
• defineşte arhitectura softului
• permite reutilizarea componentelor
UML-ul poate fi folosit pentru [4] [10]:
• definirea graniŃelor sistemului şi funcŃiilor lui majore folosind cazurile de
utilizare şi actorii
• reprezentarea structurii statice a sistemului folosind diagramele de clase
• modelarea comportamentului obiectelor cu ajutorul diagramelor de tranziŃie a
stărilor (DTS)
• reprezentarea arhitecturii fizice a implementării cu ajutorul diagramelor de
componente şi de amplasare (DCA)
extinderea funcŃionării cu ajutorul stereotipurilor.
Câteva date semnificative referitoare la apariŃia şi evoluŃia UML-ului [48]:
• În octombrie 1994, Gradz Booch lider ştinŃific la Rational Corporation, autor
ala metodei ce-i poartă numele şi a unor cărŃi de referinŃă, în domeniu face
echipă cu James Rumbaugh, autorul principal al metodei OMT, pe care-l
determină să-şi părăsească (cel puŃin temporar) vechiul loc de muncă (General
Electric) şi să treacă la firma Rational. După un an de activitate Booch şi
Rombaugh, prezintă în octombrie 1995 cu ocazia conferinŃei OOPSALA,
caracteristicile de bază ale unei noi metode de analiză şi proiectare, rezultată
prin unificarea Metodei lui Booch (OOD) cu OMT, metodă denumită Metoda
unificată (Unified Method). Prima documentaŃie a metodei menŃionată anterior
a fost făcută publică în decembrie 1995, având numărul de versiune 0.8. La
sfârşitul aceluiaşi an celor doi li se alătură şi Ivar Jacobson.
• În iunie 1996 apare versiunea 0.9, urmată la scurt timp, octombrie 1996, de
apariŃia versiunii 0.91. Versiunea 0.9 aduce şi schimbarea denumirii din
Metoda unificată (Unified Method) în Limbajul unificat de modelare (Unified
Modeling Language). Cooptarea lui Jacobson în echipă se concretizează
printre altele în detalierea conceptului de cazuri de utilizare (use-case) şi
prezentarea unei descrieri mai amănunŃite pentru diagramele cazurilor de
utilizare. Conceptul de stereotip este mai bine explicitat, se modifică
denumirile unor diagrame.
204
• La 11 ianuarie 1997 este prezentată versiunea 1.0 care, însoŃită de o

documentaŃie mult mai detaliată decât versiunile precedente, este trimisă către
OMG pentru standardizare.
• 1 septembrie 1997, a reprezentat un alt moment deosebit de important.
Rational şi alte firme care sprijină UML, printre care şi doi foşti competitori,
IBM/ObjectTime şi Taskon/Reich, a propus OMG o nouă versiune 1.1.
Noutatea semnificativă pentru această versiune o reprezintă introducerea
limbajului OCL, un limbaj folosit pentru descrierea regulilor de corectitudine
ale metamodelului UML.
• La 17 noiembrie 1997, OMG a anunŃat adoptarea specificaŃiei UML ca limbaj
standard de modelare.
• În iunie 1999 apare versiunea 1.3 al limbajului.
• Anul următor apare versiunea 1.4.
• În anul 2003 apare versiunea 1.5 al limbajului.
• Anul 2004 aduce cu el apariŃia versiunii 2.0 al limbajului, care aduce cu el mai
multe noutăŃi.
• În februarie 2009, apare versiunea 2.2 al limbajului
Schimbarea denumirii din Metoda unificată în Limbaj de Modelare Unificat a fost
justificată prin [30]:
• reacŃiile primate din partea utilizatorilor care au sugerat că este mult mai
important să se acorde o atenŃie sporită conceptelor utilizate în dezvoltarea
aplicaŃiilor. Recomandările referitoare la desfăşurarea etapelor de realizare şi
înlănŃuirea lor au fost lăsate în planul secundar,
• faptul că eforturile de unificare au fost concentrate asupra limbajului grafic de
modelare, asupra semanticii lui şi abia după aceea asupra modului de utilizare
a conceptelor,
• UML a fost conceput ca un limbaj universal care să fie utilizat la modelarea
sistemelor (indiferent de tipul şi scopul pentru care au fost construite), la fel
cum limbajele de programare sunt folosite în diverse domenii.
Sublinierea aspectelor de limbaj nu semnifică nicidecum ignorarea modului de folosire
a lor. UML presupune că metodologia este “ghidată” de cazurile de utilizare, că ea se bazează
pe arhitectura sistemului, iar procesul de aplicare a metodologiei este iterativ şi incremental.
Detaliile acestui proces trebuie adoptate la domeniul aplicaŃiei, la modul de organizare
al echipei de realizatori, la experienŃa echipei. UML nu tratează aspecte de metodologie,
permiŃând astfel separarea limbajului de modelare de procesul aplicării metodologiei.
Obiectivele principale ale unificării metodologilor au fost următoarele [4] [7]:
• să permită modelarea de sistem de la concept şi până la interfeŃe executabile,
folosind tehnici orientate obiect
• să fie abordate aspecte de scală, inerente sistemelor complexe cu funcŃii critice
• să fie creat un limbaj de modelare utilizabil atât de oameni cât şi de
calculatoare
5.9.2. Definirea limbajului

Pentru definirea limbajului sunt folosite patru documente: UML Semantics, UML
Notation Guide şi UML Extetions.
UML Semantics este un model logic, cuprinzând semantica declarativă fără detaliile
de implementare, este documentul principal care descrie limbajul în trei secŃiuni [37]:
205
• Sintaxa abstractă (Abstract syntax) – în care diagramele claselor UML sunt

folosite pentru a defini metamodelul UML, conceptele sale (metaclase),
relaŃiile şi restricŃiile. Sunt incluse şi definiŃiile conceptelor. Metamodelul,
modelul elementelor modelate, este prezentat ca un limbaj pentru specificarea
modelului obiect. Scopul metamodelului UML este să furnizeze un singur,
comun şi definitiv sens al sintacticii şi semanticii elementelor UML.
• Regulile de corectitudine (Well-formedness rules) – în care sunt definite
regulile şi restricŃiile modelului. Object Constraint Language (OCL) este un
limbaj specific care foloseşte logica simplă pentru specificarea proprietăŃilor
invariante ale sistemului şi relaŃiile. Este prima contribuŃie IBM la UML,
dezvoltată în cadrul limbajului de modelare pentru sistemele informatice din
mediile de afaceri. Furnizează facilităŃi pentru formalizarea semanticii
limbajului, pentru exprimarea structurii modelului şi a restricŃiilor.
• Semantica (Semantics) – în care semnificaŃia modelului şi cerinŃele
suplimentare, non-funcŃionale, sunt specificate ca cerinŃe textuale.
În descrierea semanticii sunt folosite tehnici formale, definiŃiile sunt prezentate riguros
matematic şi fără ambiguităŃi, folosind elemente de calculul predicatelor. Totuşi valoarea
acestor definiŃii nu are înŃeles universal. Chiar dacă se pot demonstra specificaŃiile
matematice, nu există căi de a proba aceste specificaŃii în contact cu cerinŃele reale din sistem.
Modelele orientate obiect au puŃină rigoare. NotaŃia lor apelează mai mult la intuiŃie
decât la definiŃiile formale.
Pot fi informale, mulŃi apelează la ele, şi acest lucru contează. Metodele orientate
obiect caută să îmbunătăŃească rigoarea fără a pierde din utilitate. O modalitate de a face acest
lucru este a defini un metamodel, o diagramă a claselor care defineşte notaŃia.
NotaŃia este partea grafică văzută în model, este sintaxa limbajului de modelare.
NotaŃia din diagrama claselor defineşte modul în care sunt reprezentate conceptele de clasă,
asociere şi multiplicitate.
UML Notation Guide este un document utilizat practic în toate metodele de analiză şi
proiectare. Este structurat în conformitate cu documentele principale (diagramele) ce pot fi
construite în procesul de aplicare a metodei. UML Notation Guide descrie notaŃiile UML şi
furnizează exemple.
Face sumarul semanticii UML, definiŃiile fiind însă în UML Semantics. Este o
reprezentare la nivelul modelului utilizatorului, care e semantic o instanŃă a metamodelului
UML.
UML Extensions cuprinde definirea extensiilor UML care sunt posibile prin folosirea
stereotipurilor (Stereotypes), valorilor etichetate (Tagged values) şi restricŃiilor (Constraints).
Sunt definite două extensii: UML Extension for the Objectory Process for Software
Engineeering şi UML Extension for Business Modeling.
Se apelează la extensii doar când este necesară introducerea de noi notaŃii şi
terminologii. Extensiile nu sunt universal acceptate, înŃelese şi suportate. Chiar fără extensii,
UML este complet aplicabil pentru multe tipuri de sisteme, domenii, metode sau procese.
Defineşte un set de concepte pentru dobândirea, partajarea şi utilizarea cunoştinŃelor împreună
cu mecanismele de extensibilitate.
Ca limbaj de modelare standardizat este deschis la extensibilitate pe scară industrială,
permite îmbunătăŃirea tacticii şi strategiei pentru creşterea valorii prin calitate şi reducere de
cost. Permite practicienilor creşterea eficienŃei având consistenŃă, standardizare şi instrumente
suportate de limbaj de modelare.
206
5.9.3. Concepte de bază

Pentru a înŃelege UML -ul trebuie înŃelese trei elemente majore şi anume:
• blocurile constructive ale UML-ului
• regulile ce dictează modul în care blocurile pot fi combinate
• mecanismele generale folosite de UML
5.9.3.1. Blocurile constructive

Există trei categorii de blocuri, anume: elemente, relaŃii şi diagrame.
Elementele sunt abstracŃii ce reprezintă piesele fundamentale într-un model. Ele se
împart în patru categorii şi anume [4] [44]:
• elemente structurale
• elemente comportamentale
• elemente de grupare
• elemente de adnotare
a) Elementele structurale sunt substantivele modelelor UML, reprezentând în cea
mai mare parte componentele statice ale modelului, cum ar fi:
1) Clasa – este cel mai important bloc constructiv al oricărui sistem orientat obiect.
Clasa este descrierea unui set de obiecte ce partajează acelaşi atribute, operaŃii, relaŃie şi
semantică putând implementa una sau mai multe interfeŃe.
Elementele componente ale clasei sunt:
• Atributele – sunt o proprietate, cu nume, a unei clase, descriind o plajă de
valori pe care instanŃele acelei proprietăŃi le poate lua;
• OperaŃiile – sunt o implementare a unui serviciu ce poate fi solicitat de orice
obiect al clasei pentru a-i afecta comportamentul. Ea este o abstactizare a unei
prelucrări ce se aplică unui obiect, partajată de toate obiectele clase.
• ResponsabilităŃile – sunt obligaŃiile unei clase.
Clasa bine structurată trebuie să îndeplinească condiŃii ca:
• să ofere abstractizarea clară a unei entităŃi ce aparŃine vocabularului
domeniului problemei sau domeniului soluŃiei;
• să includă o mulŃime restrânsă şi bine definită de responsabilităŃi;
• să ofere o separare clară a abstractizărilor şi a implementărilor;
• să fie inteligibilă şi simplă, dar în acelaşi timp extensibilă şi adaptabilă.
Simbolul folosit de o clasă este următorul:
Nume_clasă
Atribute
OperaŃi
ResponsabilităŃi
2) InterfaŃa – este o colecŃie de operaŃii care specifică un serviciu al unei clase sau al
unei componente. Se foloseşte simbolul:
Nume
207
3) Colaborarea – defineşte o interacŃiune, o colaborare şi este un ansamblu de

elemente ce lucrează împreună pentru a oferi un comportament colectiv mai important decât
suma comportamentelor elementelor.
Are simbolul:
Nume_colaborare
4) Cazul de utilizare – este o descriere a seturilor de secvenŃe de acŃiuni pe care le

execută un sistem, conducând la un rezultat observabil ce prezintă importanŃa pentru un
anumit actor. Se reprezintă astfel:
Nume_caz_de_utilizare
5) Clasă activă – ce a cărei obiecte posedă unul sau mai multe procese sau fire de
execuŃie şi prin urmare pot iniŃia controlul activităŃilor.
6) Componentă – este o parte fizică înlocuibilă a unui sistem ce oferă implementarea
unu set de interfeŃe. Se reprezintă astfel:
Nume_
componenta
7) Nodul – este un element fizic care există la momentul execuŃiei şi reprezintă o

resursă de calcul care are cel puŃin memorie şi adesea capacităŃi de procesare. Se reprezintă
astfel:
Nume_
nod
Ultimele trei categorii sunt asemănătoare claselor şi ele descriu mulŃimi de obiecte cu
aceleaşi atribute, operaŃii, relaŃii şi semantică. Fiind totuşi suficient de diferite şi folosite în
modelarea unui sistem orientat obiect.
Ultimele două elemente sunt elemente fizice, iar celelalte sunt elemente logice sau
conceptuale.
b) Elemente comportamentale – sunt părŃi dinamice ale modelului UML, reprezentând
comportamentul modelului în timp şi spaŃiu. Acestea sunt verbele modelului şi există două
categorii de elemente comportamentale:
1) InteracŃiune – ce este un comportament ce cuprinde un set de mesaje schimbat între
o mulŃime de obiecte într-un context particular, pentru a realiza un scop specific.
O interacŃiune implică un număr de alte elemente, incluzând mesaje, secvenŃe de
acŃiuni şi legături. Se reprezintă astfel:
208
2) Maşina stării – este un comportament ce specifică secvenŃa stării prin care trece un
obiect sau o interacŃiune în cursul existenŃei sale, ca răspuns la evenimente, împreună cu
răspunsurile la aceste evenimente.
Se reprezintă astfel:
Nume
Semantic aceste elemente sunt de obicei conectate la diverse elemente structurale, în

primul rând clase, colaborări şi obiecte.
c) Elemente de grupare – sunt părŃile organizaŃionale ale modelelor UML şi avem un
singur tip aici, anume : pachetul.
Pachetul – este un mecanism general pentru organizarea elementelor grupate. În
pachet pot fi plasate elemente structurale, elemente comportamentale şi chiar elemente
grupate. Se reprezintă astfel:
Nume_pachet
d) Elemente de adnotare – sunt părŃile explicative ale modelelor UML. Are un singur
tip de element, anume nota, care este un simbol pentru marcarea restricŃiilor sau comentariilor
ataşate unui element sau unei colecŃii de elemente. Se reprezintă astfel:
Nume_nota
Alte componente utilizate:

e) RelaŃii – abstracŃiuni ce leagă elementele între ele. Aceasta este o conexiune între
elemente. În modelarea obiectuală sunt patru tipuri de relaŃii, anume:
1) DependenŃa – care este o relaŃie semantică între două elemente, în care o schimbare
a unui element (cel dependent) poate afecta celălalt element (cel dependent). DependenŃele
sunt folosite atunci când se doreşte indicarea faptului că un element este folosit de altul. Se
reprezintă astfel:
2) Asocierea – este o relaŃie structurală ce descrie un set de legături, o legătură fiind o
conexiune între obiecte şi se reprezintă astfel:
0 ... 1 *
rol rol
Pe lângă asocieri se mai folosesc şi următoarele noŃiuni:
• Nume – folosit la descrierea naturii relaŃiei
• Rol – dacă o clasă are un rol specific în acea relaŃie
• Multiplicitate – arată numărul de obiecte ce se pot conecta prin intermediul
unei instanŃe a unei asocieri
• Agregarea – este o asociere ce modelează o relaŃie de tipul “are un”, ceea ce
înseamnă că un obiect al întregului conŃine (are) obiecte părŃi.
209
Multiplicitate
1 .... * Nume *
Clasa_2
Clasa_1
Rol_1 Rol_2 1
Agregare
*
Clasa_3
3) Generalizare – se face pentru a arăta existenŃa unor relaŃii de tip părinte/copil. Ea

este o relaŃie de specializare în care obiectele elementului specializat (copil) pot fi substituite
prin obiecte ale elementului generalizat (părinte). Se reprezintă astfel:
4) Realizare – este o relaŃie semantică între calificatori, unde calificatorul arată un

contact cu alt calificator şi garantează să-l execute. Se reprezintă astfel:
La modelarea relaŃiilor în UML se recomandă:

• folosirea dependenŃelor atunci când relaŃia modelată nu este structurată;
• folosirea generalizării numai când există o relaŃie de tipul “este de tipul”, iar
moştenirea multiplă se poate înlocui prin agregare;
• evitarea introduceri de relaŃii de generalizare ciclice;
• păstrarea relaŃiilor de generalizare cât mai balansate, părŃile de moştenire nu
trebuie să fie prea “adânci” şi nici prea “late”;
• folosirea asocierilor în primul rând acolo unde sunt relaŃii structurale între
obiecte.
f) Diagramele – sunt prezentări grafice ale unui set de elemente, cel mai adesea
exprimate ca un grafic cu noduri (elemente) şi arce (relaŃii).
5.9.3.2. Reguli UML

Blocurile constructive UML nu pot fi grupate oricum, aleator, sunt reguli detaliate
pentru definirea modelelor bine formate.
Modelul bineformat este unul auto-consistent semantic şi în armonie cu modelele sale
înrudite. UML-ul are reguli semantice pentru: nume, denumire de reprezentare, vizibilitate,
integritate şi execuŃie.
Se admit şi modele mai puŃin decât bineformate, în sensul că se pot admite şi modele
cu elemente ascunse, modele incomplete sau modele inconsistente, cel puŃin pentru iteraŃiile
preliminare ale procesului de dezvoltare.
210
5.9.3.3. Mecanisme generale UML

Dezvoltarea modelelor UML este simplificată prin prezenŃa a patru mecanisme
generale, anume: specificaŃiile, ornamentele, diviziuni generale şi mecanisme de extensie.
a) SpecificaŃiile – la fiecare parte a notaŃiei grafice UML se ataşează o specificaŃie care
oferă o descriere textuală a sintaxei şi semanticii acelui bloc constructiv. În timp ce notaŃia
grafică UML se foloseşte pentru vizualizarea unui sistem, iar specificaŃiile UML se folosesc
pentru prezentarea detaliilor sistemului.
b) Ornamentele (odornments) – Notele – sunt cel mai important tip de ornamente.
Nota – este un simbol grafic de reprezentare a constrângerilor sau comentariilor ataşate unui
element sau unei colecŃii de elemente. Se reprezintă astfel:
Comentariu
Notele se folosesc numai pentru acele cerinŃe, observaŃii, revederi şi explicaŃii, care nu
pot fi explicate în mod simplu sau inteligibil, utilizând caracteristicile UML -lui.
c) Diviziuni generale – aici avem două tipuri:
• diviziunea de clasă/obiect – unde o clasă este o abstracŃie, în timp ce obiectul
este o manifestare concretă a aceleaşi abstracŃii;
• separaŃia interfaŃă/implementare – o interfaŃă declară un contract, iar o
implementare reprezintă o realizare concretă a aceluiaşi contract, responsabilă
pentru realizarea integrală a semantici complexe a interfeŃei.
d) Mecanisme de extensie – permit extinderea limbajului în modalităŃi controlate şi
aici intră: stereotipuri, valori etichetă şi constrângeri.
Stereotipul – extinde vocabularul UML, permiŃând crearea de noi tipuri de blocuri
constructive derivate din cele existente, dar care sunt specifice unei anumite probleme.
Valoarea etichetă – extinde proprietăŃile unui bloc constructiv UML, permiŃând
crearea de noi informaŃii în cadrul specificaŃiei elementului.
Constrângerea – extinde semantica unui bloc constructiv UML, permiŃând adăugarea
de noi reguli sau modificarea unora existente. Se reprezintă astfel:
<< subsistem >>

Facturare
{ versiune 6.0}
{ doc = cmd sau factura}
5.9.4. Diagrame UML

Modelarea unei aplicaŃii necesită specificarea realităŃii astfel ca să se înŃeleagă mai
bine sistemul dezvoltat. Diagramele sunt mijloacele prin care aceste blocuri constructive ale
UML -ului sunt vizualizate. Ele prezintă grafic o mulŃime de elemente, reprezentate ca un graf
conex de noduri (elemente) şi arce (relaŃii).
UML 2.0 conŃine un număr de 13 diagrame de descriere a unui sistem informatic şi
semantica acestor diagrame. El ne propune şi un proces de utilizare a acestor digrame în
construcŃia unei aplicaŃii.
Cele treisprezece sunt [37]:
• de clasă
• de componente
• de structuri compuse
211
• de desfăşurare
• de obiecte
• de pachete
• de activităŃi
• de maşini de stare
• de cazuri de utilizare
• de comunicare
• de interacŃiuni generale
• de secvenŃă
• de cronometrare
Acestea se pot împărŃite în trei mari categorii:
• Diagrame de structură – Prezintă elementele unei specificaŃii independent de
timp. Includ: diagramele de clase, structuri compuse, componente, desfăşurare
(deployment), obiecte şi pachete
• Diagrame de comportament – Prezintă trăsăturile comportamentale ale
sistemului. Includ: diagramele de activităŃi, maşini de stare şi cazuri de
utilizare, precum şi cele 4 diagrame de interacŃiune
• Diagrame de interacŃiune – Scot în evidenŃă interacŃiunile dintre obiecte.
Includ: diagramele de comunicare, interacŃiuni generale (interaction overview),
secvenŃe şi cronometrare (timing)
Diagramele semnalizate cu îngroşarea denumirii, au fost introduse în UML 2.0. În
continuare prezentăm detaliat nouă tipuri de diagrame.
5.9.4.1. Diagrama cazurilor de utilizare (DCU)

Comportamentul unui sistem din punctul de vedere al utilizatorului este descris cu
ajutorul cazurilor de utilizare. Ele permit utilizatorilor să-şi structureze cerinŃele, să definească
modul în care vor interacŃiona cu sistemul pentru a obŃine rezultatul dorit.
Un caz de utilizare este iniŃiat întotdeauna de un actor şi exprimă o funcŃie a
sistemului, declanşată ca răspuns. FuncŃionalitatea completă a sistemului este dată de
totalitatea cazurilor de utilizare.
Diagrama cazurilor de utilizare include actorii şi cazurile de utilizare. Fiecare
diagramă conŃine un set complet de evenimente iniŃiate de unul sau mai mulŃi actori şi
specifică interacŃiunea care are loc între actori şi sistem.
Ca abstracŃii ale dialogului între actori şi sistem, cazurile de utilizare descriu
interacŃiuni potenŃiale fără a intra în detaliile fiecărui scenariu. Specifică doar când se
declanşează evenimentele, ce acŃiuni determină şi când se termină, fără a cuprinde detalii
funcŃionale.
Grafic cazul de utilizare este reprezentat de o elipsă, iar fiecare caz trebuie să aibă un
nume distinct. Numele este format dintr-un şir de caractere, fiind “Nume_simplu”,
“Nume_cale” – este numele cazului de utilizare prefixat de numele pachetului din care face
parte acesta. Exemplu:
Simple Name: Plasează comanda
Path Name: Senzor: Calibrare locaŃie
212
Actorii sunt roluri jucate de diverse persoane sau sisteme informatice şi care
interacŃionează cu sistemul informatic aflat în dezvoltare. Important este de reŃinut faptul că o
persoană poate juca mai multe roluri şi un rol poate caracteriza mai multe persoane. Grafic
actorii în UML sunt reprezentaŃi de un omuleŃ stilizat având la subsol un text ce arată rolul
jucat de actor. Astfel:
Administrator
Determinarea actorilor se face răspunzând la întrebările:
• cine – este interesat;
• cine – modifică datele;
• cine – se interfaŃează sau
• cine - doreşte informaŃia din sistem.
Actorul se mai poate defini ca un set de roluri pe care utilizatorul le foloseşte când
interacŃionează cazurile de utilizare. Poate fi un rol uman, un dispozitiv hard sau orice alt
sistem.
InstanŃa unui actor, este o interacŃiune individuală cu sistemul.
Actorii nu fac parte din sistem.
Comportamentul unui caz de utilizare se poate specifica prin descrierea fluxului de
evenimente. Acestea trebuie să indice cum şi când începe şi se încheie cazul de utilizare, când
interacŃionează cu actorii, ce obiecte sunt schimbate, fluxul de bază şi cel alternativ al
comportamentului.
Cazul de utilizare foloseşte un set de secvenŃe, este de preferat ca descrierea acestuia
să fie separată pe fluxuri alternative.
Practic un caz de utilizare modelează un dialog între actor şi sistemul informatic.
MulŃimea cazurilor unui sistem reprezintă totalitatea modalităŃilor în care sistemul poate fi
folosit. Cazurile de utilizare depind de elementele [4]:
• sunt unităŃi de sine stătătoare şi bine delimitate
• trebuie să fie iniŃiate de un actor şi terminarea să fie văzută de un actor
• trebuie să îndeplinească anumite scopuri de logică a problemei
• trebuie să lase sistemul într-o stare stabilă.
Ele sunt orientate pe scop şi reprezintă cea ce sistemul trebuie să facă şi cum. Acestea
sunt neutre din punct de vedere tehnologic, putând fi utilizate în orice proces sau arhitectură
de aplicaŃie.
Fiecare caz de utilizare ce apare în una din diagramele ce modulează funcŃionalitatea
sistemului informatic şi trebuie să fie însoŃite de un document de descrierea sa şi care trebuie
să respecte şablonul: Nume, Descriere, Autori, Stare, Prioritete, PrecondiŃie, PostcondiŃie,
Cale principală, Căi alternative, Căi de excepŃie.
Aceste secvenŃe sunt numite scenarii.
Implementarea cazurilor de utilizare se poate face creând o societate a claselor şi a
elementelor ce lucrează împreună. Societatea elementelor include structura statică şi cea
dinamică, numindu-se colaborare.
Ea modelează aspecte dinamice ale sistemului şi este folosită pentru modelarea
comportamentului sistemului, subsistemului sau clasei. DCU -ul este o diagramă ce conŃine
un set de cazuri de utilizare, actori şi relaŃiile dintre acestea, mai poate conŃine restricŃii şi
pachete folosite la gruparea elementelor.
213
Are următoarea formă generală:
Caz_de_utilizar1
Actor_1
Caz_de_utilizare3
Actor_2 Caz_de_utilizare2
Figura 5.10 Forma generală a diagramei use-case

RelaŃia dintre actori şi cazurile de utilizare este o relaŃie de asociere (comunicare),
direcŃia de navigare a relaŃiei (săgeata) ne sugerează cine iniŃiază comunicarea. În general
comunicarea între actori şi caz de utilizare este bidirecŃională, conform figurii:
Gestiunea facturilor
Contabil
Figura 5.11 Exemplu de use-case

RelaŃiile între cazurile de utilizare sunt:
• relaŃia de utilizare ce are loc între două cazuri de utilizare şi ce foloseşte
funcŃionalitatea acestuia. Se reprezintă grafic printr-o linie având la capătul
corespunzător cazului de utilizare un triunghi şi eticheta cu stereotipul
<<uses>>, care permite extinderea elementelor modelare de bază, pentru a
crea noi elemente
• relaŃia de extindere ce este folosită pentru a sugera un comportament opŃional,
un comportament ce are loc în anumite condiŃii sau fluxuri diferite ce pot fi
selectate pe bază de selecŃii diferite ce pot fi selectate pe baza unui actor.
Grafic se reprezintă identic cu precedenta relaŃie, dar are eticheta <<extend>>,
exemplu în figura următoare
• relaŃia de includere este o instanŃă a cazului de utilizare sursă include şi
comportamentul descris de un alt caz de utilizare. Acest tip de relaŃie se
foloseşte pentru simplificarea diagramei cazurilor de utilizare în situaŃii
complexe. Se foloseşte stereotipul <<include>>
RelaŃiile dintre actori sunt:
• relaŃia de generalizare ce semnifică faptul că un actor poate interacŃiona cu un
sistemul în toate modalităŃile prin care interacŃionează cu altul. Se va
reprezenta ca o relaŃie de extindere între două cazuri de utilizare fără a avea
stereotip.
• relaŃia de dependenŃă ce semnifică faptul că pentru a interacŃiona cu sistemul
informatic prin intermediul unui caz de utilizare, un actor depinde de alt actor.
Se reprezintă grafic printr-o linie frântă având în capăt o săgeată.
214
Diagrama cazurilor de utilizare corespunzătoare aprovizionării cu mărfuri:
Figura 5.12 Aprovizionare cu marfă

Descrierile pot fi textuale. În această situaŃie trebuie să se verifice dacă cerinŃele
exprimate formal au fost alocate cazului de utilizare specificat. Fiind prezentate în limbajul
utilizatorului, neconŃinând un vocabular orientat obiect, pot fi aplicate oricărui sistem
dinamic, dacă există sau nu intenŃia de construire a unui sistem orientat obiect.
În modelarea unui caz de utilizare static al sistemului, DCU se poate aplica în două
feluri:
• modelarea contextului unui sistem, ce presupune trasarea de linii în jurul
întregului sistem şi aserŃiunea prin actorii aflaŃi în afara sistemului
interacŃionează cu linia
• modelarea cerinŃelor sistemului, care implică specificarea a ceea ce trebuie să
facă sistemul, indiferent de modul în care acesta va realiza cerinŃele
Cu DCU -ul se poate modela conŃinutul sistemului, punând în evidenŃă actorii din
afara lui. Lucru ce se realizează astfel:
• actorii ce sunt identici se organizează sub forma unei ierarhii folosind relaŃiile
de generalizare şi specializare
• se arată actorii ce înconjoară sistemul, alegând acele grupuri ce necesită ajutor
din partea sistemului ca să-şi îndeplinească sarcinile ce sunt necesare pentru a
executa funcŃiile sistemului
• acolo unde este necesar se identifică un stereotip pentru fiecare tip de actor
• se populează DCU-ul cu aceşti actori şi se specifică căile de la fiecare actor
spre cazurile de utilizare
CerinŃele sistemului por fi exprimate în diverse forme, de la text nestructurat la
expresii într-un limbaj formal.
La stabilirea cazurilor de utilizare se procedează astfel [44]:
• se stabileşte contextul sistemului prin identificarea actorilor ce-l înconjoară
• comportamentul fiecărui actor este considerat previzibil
• se identifică componentele obişnuite ca fiind cazuri de utilizare
215
• se transformă comportamentul obişnuit într-un caz de utilizare, iar

comportamentul variabil într-un nou caz de utilizare ce extinde mai multe linii
de flux principale
• se modelează cazurile de utilizare, actorii şi relaŃiile dintre ei într-un DCU;
• se adaugă cazuri de utilizare pentru cerinŃele non-funcŃionale
În exemplul următor prezentăm o aplicaŃie web, care oferă profesorilor o modalitate de
a vedea ce proiecte şi-au ales studenŃii, iar pentru un anumit proiect să vadă de care studenŃi a
fost ales. Un profesor trebuie să aibă posibilitatea de a vedea care sunt proiectele propuse de
studenŃi. Mai mult, el are dreptul de a aproba sau de a respinge un astfel de proiect. Atunci
când un proiect este aprobat el devine vizibil în lista de proiecte disponibile. Un proiect
respins nu este şters imediat din baza de date, profesorul putându-se răzgândi, urmând a-l
accepta ulterior. Un profesor poate să vadă lista tuturor proiectelor existente, lista proiectelor
alese de cel puŃin un student şi lista proiectelor nealese de nici un student.
Figura 5.13 Alegerea proiectelor de către studenŃi

Descrierea unui caz de utilizare constă în unul sau mai multe “scenarii”, numite
instanŃe ale cazului de utilizare, şi include următoarele elemente:
• începutul cazului de utilizare – evenimentul care declanşează cazul de
utilizare
• sfârşitul cazului de utilizare – evenimentul care provoacă sfârşitul cazului de
utilizare
• interacŃiunea actorilor în cadrul cazului de utilizare
• schimbul de informaŃii în timpul interacŃiunilor între sistem şi actori
216
• cronologia şi originea informaŃiilor – momentul înregistrării lor în interiorul

sau în exteriorul sistemului
• repetările de comportament – care pot fi descrise în secvenŃe de cod prin
structuri repetitive
• situaŃiile opŃionale, folosind o formulare de tipul – ”Actorul alege unul
dintre evenimentele următoare, eventual de mai multe ori”
5.9.4.2. Diagrama de clase

Ele fac parte din categoria diagramelor statice şi descriu structura internă a sistemului
informatic prin identificarea claselor, a atributelor şi a operaŃiilor acestora şi a relaŃiilor dintre
clase. ConstrucŃia lor are loc în faza de elaborare a sistemului informatic, fiind cele mai
importante în această fază.
Selectarea claselor necesită anumite deprinderi. O abordare metodică a determinării
claselor ce modelează soluŃia unei probleme informatice este aceea de a extrage substantivele
esenŃiale din documentul de specificaŃie. O metodă mult mai rapidă este aceea de a extrage
toate substantivele care apar în diagrama de cazuri de utilizare (atât în denumirile actorilor cât
şi a cazurilor de utilizare). După dobândirea unei anumite experienŃe în domeniu, în acest
proces de selectare a substantivelor intervine şi o filtrare a acelor substantive care nu vor
reprezenta clase ‘bune’ (multe dintre acestea reprezintă de fapt atribute ale unor alte clase din
domeniul problemei) – ex. cont bancar.
Odată completată lista iniŃială de substantive se vor aplica o serie de 7 reguli de
filtrare. Se vor elimina toate clasele candidat care au una dintre următoarele caracteristici [4]:
1. Este redundantă: două substantive care reprezintă acelaşi lucru sunt redundante
(ex. maşină – automobil);
2. Este irelevantă: substantivul nu este relevant pentru sistemul modelat;
3. Este atribut: substantivul reprezintă mai degrabă un atribut al unei clase decât o
clasa în sine (ex. cont bancar);
4. Este operaŃie: substantivul exprimă un calcul sau proces care trebuie realizat (ex.
calcul discount);
5. Este rol: substantiv exprimă o stare a unui obiect (ex. maşină bună);
6. Este eveniment: (ex. listarea trebuia făcută o dată pe săptămână - săptămână nu
reprezintă un nume de clasă);
7. Este construcŃie de implementare: denumeşte un dispozitiv fizic imobil utilizat de
sistem (ex. imprimantă). În aplicaŃiile în timp-real se utilizează modelarea prin clase a
acestor dispozitive, proces care poartă numele de reificare.
Objectory introduce 3 tipuri de clase (marcate în UML ca stereotipuri) - figura 5.13.:
a. Clase entităŃi (sau clase domeniu) – reprezintă nucleul unei aplicaŃii, reŃin
informaŃii legate de entităŃile persistente şi capturează serviciile ce conduc majoritatea
interacŃiunilor în aplicaŃie. De obicei clasele entitate trebuie să:
• înmagazineze şi redea valori de atribute
• creează şi ştergere entităŃi
• furnizeze un comportament dependent de modificarea stării entităŃii
b. Clase de interfaŃă – reprezintă graniŃa dintre actorii care doresc să interacŃioneze
cu aplicaŃia şi clasele entitate. Majoritatea sunt componente ale interfeŃei utilizator (fiecare
cutie de dialog este o clasă de interfaŃă), modelează comunicarea cu alte aplicaŃii sau
reprezintă clase wrapper peste anumite componente soft. Se determină studiind:
• modul în care doresc actorii să creeze entităŃi
• interfaŃa între aplicaŃie şi alte sisteme
• modalitatea de vizualizare a informaŃiilor (rapoarte)
217
c. Clase de control (controller) – coordonează activitatea în interiorul aplicaŃiei. Se

creează câte o clasă controller pentru fiecare caz de utilizare. Pot juca unul din următoarele
roluri:
• modelarea unui comportament tranzacŃional
• secvenŃă de control specifică unuia sau mai multor cazuri de utilizare
• serviciu ce separă obiectele entitate de obiectele de interfaŃă
Figura 5.14 Reprezentarea grafică a claselor în UML

RelaŃii între clase – asigură posibilitatea colaborării între obiectele unui sistem
informatic. În UML se pot modela trei tipuri de relaŃii între clase:
1. Asociere – modul în care obiectele unei clase sunt conectate cu obiectele altei clase.
Asocierile pot fi extrase din cazurile de utilizare sau din tabela de evenimente ('Clientul
plasează Comenzi', 'Documentul conŃine Cuprins'). Reprezentarea grafică (figura 6.15) este o
linie (sau segmente de dreaptă) care uneşte clasele asociate având, opŃional, o etichetă care
sugerează natura relaŃiei dintre acestea. Atunci când asocierea nu este bidirecŃională, capetele
liniei conŃin o săgeată.
Multiplicitatea se poate specifica la ambele capete ale unei asocieri şi poate avea valori
concrete (1,4), intervale de valori (0..5) sau poate fi nedefinită (*). În cazul în care nu se
specifică, multiplicitatea este considerată implicit 1.
218
De asemenea, capetele unei asocieri pot fi etichetate cu nume de rol care definesc rolul
jucat de obiectul unei clase în cadrul asocierii. Atât multiplicitatea cât şi numele de rol
influenŃează modalitatea de implementarea (sau generare automată) a codului sursă pe baza
modelului.
0..*
Persoană are ► Maşina
1..* ◄ aparŃine
Figura 5.15 Exemplu de asociere

a. Agregare – modelează o relaŃie de tip 'parte/întreg' în care obiectul/obiectele parte
pot face parte din mai mulŃi întregi (în momente de timp diferite). În reprezentarea grafică se
adaugă un romb gol la capătul corespunzător clasei 'întreg'.
Echipa * * Persoana
membru
Figura 5.16 Exemplu de agregare

Dacă părŃile “trăiesc” în interiorul întregului, şi vor fi distruse împreună cu acesta, vom
spune că avem o relaŃie de agregare compusă. Multiplicitatea pe partea “întreg” trebuie să fie
(0..1) iar pe partea “parte” poate fi orice interval. Agregarea compusă formează un arbore de
părŃi, pe când o agregare partajată formează o reŃea. Ca modalităŃi de reprezentare se pot alege
oricare din notaŃiile de mai jos:
*
Text
*
ConŃine Listbox
Fereastra
*
Button
*
Meniu
Fereastra
Text
Listbox
Button
Meniu
Figura 5.17 ModalităŃi de reprezentare pentru o relaŃie de agregare compusă
219
b. Compunere – modelează o relaŃie de tip 'parte/întreg' în care obiectul/obiectele parte

compun un singur întreg pe toată perioada ciclului de viaŃă şi se distrug în momentul
distrugerii întregului. În reprezentarea grafică se adaugă un romb plin la capătul corespunzător
clasei 'întreg'.
Figura 5.18 Exemplu de compunere
c. Legătură (clasă asociere) – reprezintă o colecŃie de atribute care caracterizează o

asociere. Clasele asociere apar atunci când nu există un mod logic de a plasa aceste atribute la
nivelul unei clase aflate în sistem.
Figura 5.19 Exemplu de clasă de asociere
d. Asociere reflexivă – asociere între obiecte ale aceleaşi clase.

soŃie Persoană
soŃ
◄căsătorit cu
Figura 5.20 Exemplu de asociere reflexivă
2. Generalizare – modelează moştenirea proprietăŃilor şi a operaŃiilor între două clase

(rafinarea, specializare a clasei).
Clasa generală poartă numele de superclasă, iar clasa specializată de numeşte subclasă.
Generalizarea apare atunci când orice exemplu de obiect al unei clase este un exemplu valid
de obiect al altei clase.
220
Vehicul
conduce ► * {abstract}
Persoana culoare
conduce(){abstract}
pornire(){abstract}
oprire(){abstract}
Automobil Vapor
conduce() conduce()
pornire() pornire()
oprire() oprire()
Figura 5.21 Reprezentarea grafică a relaŃiei de generalizare/specializare în UML
3. DependenŃă – este utilizată atunci când modificarea unei clase are impact asupra
comportamentului/stării altei clase (de obicei atunci când o clasă utilizează o altă clasă ca
argument pentru una din operaŃiile sale).
Figura 5.22 Reprezentarea grafică a relaŃiei de dependenŃă în UML
Pentru a defini metode ce trebuie să fie moştenite de către subclase UML permite
definirea claselor abstracte.
O clasă abstractă este o clasă care nu este instanŃiabilă dar ale cărei clase
descendente pot avea instanŃe. Clasele abstracte pot fi particularizate prin specializare şi
extindere în clase concrete. O clasă este desemnată ca abstractă prin adăugarea proprietăŃii
"Abstract" pentru fiecare element generalizabil al clasei.
Definirea claselor abstracte permite folosirea polimorfismului. Polimorfismul
desemnează proprietatea unui element de a lua mai multe forme. În informatică termenul
desemnează un concept conform căruia un nume de obiect poate desemna instanŃe ale unor
clase diferite dar provenite din aceeaşi arborescenŃă. Polimorfismul operaŃiilor desemnează
221
posibilitatea de a declanşa operaŃii diferite ca răspuns la acelaşi mesaj. Altfel spus, o operaŃie
este polimorfă dacă realizarea sa are mai multe forme.
În exemplul de mai jos, între Persoană şi Autovehicul următoarea relaŃie: o Persoană
poate avea zero, unul sau mai multe Autovehicule.
Figura 5.23 Diagrama claselor pentru o persoană, care poate avea una sau mai multe
autovehicule
Diagrama claselor în cazul sistemului informatic privind aprovizionarea cu mărfuri
este prezentat în figura 5.24.
Figura 5.24 Diagrama claselor pentru aprovizionare cu mărfuri
5.9.4.3. Diagrama de pachete

Pentru sistemele informatice complexe modelele statice conŃin zeci de entităŃi.
Volumul mare de clase poate fi asimilat şi înŃeles cu mai mare uşurinŃă de către membri
echipei de dezvoltare dacă se realizează mai multe diagrame de clase, grupând laolaltă clase
cu anumite caracteristici comune (de ex. un criteriu de grupare poate fi dat de tipurile claselor:
de interfaŃă, entitate şi de control).
Pachetul este o grupare de mecanisme, prin care toate tipurile de elemente model pot fi
conexate şi reutilizate. UML permite definirea pachetelor astfel: “mecanisme (privite drept)
222
scopuri generale(utilizate) pentru organizarea elementelor în grupuri semantice corelate şi

conexate din punct de vedere semantic”. Toate elementele unui model ce sunt cuprinse, într-
un mod sau în altul într-un pachet se numesc conŃinutul pachetului.
Gruparea mecanismelor pentru un model de organizare trebuie să fie diferită, ceea ce
conduce la restricŃia potrivit căreia instanŃele pachetelor nu pot avea aceeaşi semantică.
Diagramele de clase pot fi construite atât asociate unui caz de utilizare (în fazele
timpurii ale analizei) cât şi unui pachet, în cadrul vederii logice. Atunci când diagramele de
cazuri de utilizare sunt complete, clasele definite la acest nivel se transferă în vederea logică
în pachete (module) bine stabilite.
Figura 5.25 Reprezentarea grafică a unui pachet
Între pachete pot exista relaŃii de un singur tip: relaŃii de dependenŃă. Spunem ca un
pachet A depinde de pachetul B dacă una sau mai multe clase din pachetul A (numit pachet
client) iniŃiază o comunicare cu una sau mai multe clase din pachetul B (numit pachet
furnizor). RelaŃiile de dependenŃă între module se reprezintă grafic printr-o linie punctată,
având la capătul corespunzător modului furnizor o săgeată (figura 5.26).
Figura 5.26 RelaŃie de dependenŃă între module

Atunci când o clasă definită într-un pachet apare într-o diagramă de clase a altui pachet
(în vederea reprezentării unei relaŃii de asociere de exemplu), compartimentul superior va
conŃine, alături de numele acesteia şi un eventual stereotip, numele pachetului din care
provine (figura 5.27).
<<Interface>> 0 ... * <<Entity>>

DLGCursuri CursOpŃional
(from Cursuri)
Figura 5.27 Clase cu stereotip
În continuare putem vedea diagrama pentru aplicaŃia web.
223
Figura 5.28 Diagrama de pachete pentru aplicaŃia web
5.9.4.4. Rafinarea diagramelor de clasă

a) Rafinarea claselor pe baza diagramelor de interacŃiune
Diagramele de interacŃiune (colaborare şi secvenŃă) şi diagramele de clase se
completează şi influenŃează reciproc. Determinarea unui obiect sau a unei interacŃiuni între
două obiecte modelate într-o diagramă de interacŃiune poate avea ca efect adăugarea unei noi
operaŃii, a unui nou atribut, a unei relaŃii (de obicei de asociere) sau chiar a unei noi clase.
De asemenea detalierea structurii şi comportamentului unei clase (de ex. adăugarea de
argumente şi valoare returnată operaŃiilor) poate afecta natura şi/sau ordinea interacŃiunilor
între obiectele dintr-o diagramă de interacŃiune.
Atât diagramele de clase cât şi diagramele de interacŃiune sunt intim legate de
diagramele de cazuri de utilizare. O primă variantă a diagramelor de clase se realizează în
urma parcurgerii tuturor cazurilor de utilizare şi a actorilor. De asemenea o diagramă de
utilizare descrie un scenariu specific unei caz de utilizare concret. Care dintre acestea trebuie
construită mai întâi? Nu există o regulă.
Diversele metode existente propun ambele abordări. Ceea ce este important de reŃinut
este faptul că atât diagramele de clase cât şi cele de interacŃiune nu se realizează ‘dintr-un
foc’, ci după o serie de iterări care presupun rafinarea paralelă a acestora.
b) Rafinarea claselor indusă de structură
Dacă un obiect al unei clase nu necesită un anumit atribut sau o anumită operaŃie,
identificate în diagrama de clase în fazele timpurii ale analizei, este foarte probabil că clasa
224
acestuia trebuie să fie descompusă în două sau mai multe clase (ex. clasa CursOpŃional având
atributele: numărLocuri, locaŃie, ziuaDasfăşurării, oraDesfăşurării, departament,
numărLocuriCursuriTotal - numărLocuriCursuriTotal nu este o informaŃie care caracterizează
obiectele clasei CursOpŃional ci mai degraba caracterizeaza un departament).
c) Rafinarea diagramelor de clase prin specializare/generalizare
OperaŃiile de generalizare şi specializare a claselor permit crearea de noi clase care nu
pot fi identificate direct prin intermediul documentului de specificare funcŃională a sistemului
informatic modelat. Astfel, generalizarea conduce la crearea de noi clase ca va conŃine
atributele, operaŃiile şi asocierile comune unui grup de clase deja identificate.
Figura 5.29 Exemplu

La baza specializării (motivul creării subclaselor) stă o relaŃie de asemănare (un obiect
al clasei B este obiect al clasei A) şi un discriminator (obiectele clasei B diferă de obiectele
clasei A prin...). Discriminatorul are o mulŃime finită de valori şi subclasele pot fi create
pentru fiecare valoare. (exemplu: o sticlă poate fi returnabilă sau nereturnabilă) această
caracteristică se poate constitui într-un atribut sau se pot crea două subclase SticlăReturnabilă
şi SticlaNereturnabilă ale clasei Sticlă, discriminatorul fiind tipul sticlei).
Ce se întâmplă atunci când se descoperă mai mulŃi discriminatori (ex. Curs:
intern/extern, obligatoriu/opŃional)? Există mai multe soluŃii:
• discriminatorul nu este relevant pentru aplicaŃie astfel încât să inducă apariŃia
unei relaŃii de specializare
• modelare folosind moştenirea multiplă
• modelare folosind agregare
În anumite situaŃii determinarea asemănării şi a discriminatorului între două clase nu
sunt suficiente pentru a modela clar relaŃia de specializare/generalizare. (ex. pătratul este un
dreptunghi cu toate laturile egale, structura şi funcŃionalitatea implementate de clasa
Dreptunghi fac dificilă specializarea din aceasta a unei clasa Pătrat; de asemenea operaŃia
inversă, clasa Dreptunghi moştenind de la Pătrat induce anomalii în condiŃiile extinderii
ierarhiei de moştenire cu clasele Patrulater, Paralelogram etc.; varianta utilizării agregării -
figura 6.26 - pare a fi cea mai potrivită în acest caz, luarea deciziei depinde în mare măsură de
natura problemei modelate). Problema utilizării agregării: La specializare atributele şi
225
operaŃiile comune subclaselor sunt poziŃionate la nivelul superclasei. Ce se va întâmpla cu

relaŃiile? Există 2 variante:
• rămân la nivelul subclaselor
• se pun la nivelul superclasei în aşa fel încât să reprezinte o reuniune a relaŃiilor
subclaselor
Ambele variante sunt corecte din punct de vedere al modelării. Cea mai bună abordare
este, în cele mai multe cazuri, prima (luarea deciziei depinde dacă se doreşte obŃinerea tuturor
informaŃiilor corespunzătoare asocierii în acelaşi timp sau separat, la nivelul subclaselor).
Figura 5.30 Rafinarea diagramelor de clase
226
Figura 5.31 Exemplu cu pătrat şi dreptunghi
Figura 5.32 Exemplu cu studenŃi
Există situaŃii în care relaŃia de specializare/generalizare a claselor în cadrul unui model

nu corespunde cu specializarea/generalizarea entităŃilor din punct de vedere logic. În figura
5.33 este prezentat un exemplu în care clasa ce implementează noŃiunea de punct în spaŃiul
tridimensional reprezintă o specializare a punctului în spaŃiul bidimensional, din punct de
vedere logic însă, lucrurile stau exact invers.
5.9.4.5. Prototipul de interfaŃă

După finalizarea diagramelor de cazuri de utilizare şi a unor prime versiuni stabile a
diagramelor de interacŃiune şi de clase se recomandă implementarea unui prototip al
sistemului informatic. Acest prototip se numeşte prototip de interfaŃă deoarece are rolul de a :
• rafina relaŃiile dintre actori şi clasele de interfaŃă
• obŃine feedback din partea beneficiarului (clientului) asupra aspectului vizual al
aplicaŃiei
• descoperi cazuri de utilizare ce descriu relaŃii între componentele interfeŃei
aplicaŃiei (interfaŃă utilizator sau interfaŃa cu alte programe)
227
Figura 5.33 Exemplu cu punct în spaŃiu
Prototipul poate conduce la descoperirea sau confirmarea cerinŃelor enunŃate. În

acelaşi timp însă un prototip poate genera o reacŃie defavorabilă din partea clientului cu
privire la termenii stabiliŃi iniŃial pentru dezvoltarea aplicaŃiei. Acesta trebuie lămurit din start
că ceea ce s-a realizat reprezintă doar o ‘carcasă’ vizuală a viitoarei aplicaŃii, fără a se avea în
vedere funcŃionalităŃile descrise în specificaŃii.
De asemenea, scopurile prototipului sunt [44]:
• stabilirea unor cerinŃe ale interfeŃei pentru funcŃionalităŃi cheie ale aplicaŃiei
• se demonstrează clientului (într-o formă vizuală) că cerinŃele proiectului au
fost bine înŃelese şi sunt realizabile
• începerea etapei de dezvoltare a elementelor standard ale interfeŃei
• construirea de cutii de dialog care, după validare, vor fi utilizate în aceeaşi
formă în faza de construcŃie
Procesul de prototipizare trebuie început cu investigarea aşteptării actorilor asupra
interfeŃei prin completarea unor chestionare specifice formate din următoarele întrebări:
• ce nivel de pregătire (informatică) necesită actorul pentru a realiza o anumită
funcŃionalitate?
• actorul are experienŃă de lucru în medii bazate pe ferestre?
• actorul are experienŃă în utilizarea altor sisteme de automatizare a procesului
modelat?
• este necesară consultarea unor documente/cataloage în paralel cu utilizarea
aplicaŃiei?
• actorul doreşte implementarea unor facilităŃi de tip ‘salvare/restaurare’?
Răspunsurile la întrebările de mai sus se notează pentru fiecare element de interfaŃă.
Deasemenea consideraŃiile generale legate de interfaŃa utilizator sunt specificate în final
(culori, mod de introducere general, tip de componente (controale) grafice utilizate etc.).
60% din utilitatea interfeŃei este data de modul în care interfaŃa utilizator se
‘potriveşte’ cu modelul mental al utilizatorului despre o anumită funcŃionalitate. InteracŃiunea
influenŃează utilitatea într-o proporŃie de 30%, iar prezentarea (modul în care aceasta arată)
contează într-o proporŃie de 10%.
Se utilizează hărŃi (diagrame) de structură a ecranului (nu sunt definite în UML) =>
descrie fluxul aplicaŃiei urmând căile principale ale cazurilor de utilizare. Se vor utiliza forme
pătrate pentru reprezentarea ferestrelor modale (necesită un răspuns dat de utilizator pentru a
se putea continua o activitate). Pentru reprezentarea ferestrelor ne-modale se vor utiliza forme
228
pătrate cu colŃurile rotunjite. DirecŃia de traversare: arată calea de navigare a ferestrelor. Prin
aceste figuri grafice se pot modela diverse elemente ale interfeŃei utilizator (cutii de dialog,
meniuri, bare de scule şi chiar ferestre conŃinând tab-uri).
5.9.4.6. Diagrama de obiecte (DO)

Obiectele sunt considerate instanŃe ale clasei, fiind construite pornind de la clase,
printr-un proces de instanŃiere. Un obiect are o identitate ce-l distinge de celelalte obiecte şi
este caracterizat printr-un ansamblu de atribute şi un anumit comportament.
Obiectelor se face prin nume individuale sau prin nume generice în locul numelor
individuale; numele obiectului este subliniat.
401_furnizor : Furnizori
Figura 5.34 Exemplu pentru diagramă de obiecte
5.9.4.7. Diagrama de activităŃi (DA)

Ea este o schemă logică ce prezintă fluxurile de control dintre activităŃi. Aceasta este
folosită la modelarea aspectelor dinamice ale sistemului şi presupune modelarea unui proces
pas cu pas. Prin ea se poate modela fluxul unui obiect ce trece din stare în stare [4] [10].
Grafic, ea este o colecŃie de vârfuri şi arce, constând stări de activitate şi stări de
acŃiune, tranziŃie şi obiecte.
Stările de activitate şi stările de acŃiune. Se numesc astfel deoarece sunt stări ale
sistemului, fiecare reprezentând executarea unei acŃiuni şi se reprezintă astfel:
Şi în interior se poate scrie orice expresie.

Stările de acŃiune nu pot fi descompuse, fiind atomice şi nu pot fi întrerupte.
Stările de activitate se pot descompune, activitatea putând fi reprezentată de altă
diagramă, acestea nu sunt atomice şi pot fi întrerupte.
Starea de acŃiune este un caz particular al stării de activitate. Între ele există anumite
diferenŃe de notaŃie: starea de activitate are părŃi în plus, acŃiuni de intrare şi de ieşire precum
şi submaşini pe care le desfăşoară activitatea.
TranziŃii, când starea de activitate sau de acŃiune sunt complete, fluxul de control trece
la următoarea stare de activitate sau la cea de acŃiune.
Acest flux se specifică folosind tranziŃiile pentru a arăta calea de la o stare la alta. În
UML tanziŃiile se reprezintă printr-o linie, iar fluxurile de control trebuie să încapă şi să se
termine undeva. Să existe o stare iniŃială notată astfel: şi una finală notată astfel:
Ramuri, în diagramă se poate include o ramură ce specifică o cale alternativă, bazată

pe o expresie booleană. Ramura se reprezintă grafic cu un romb astfel:
Pe fiecare tranziŃie care pleacă din acest simbol se plasează o expresie booleană ce se
evaluează numai când se intră în ramură.
BifurcaŃiile sunt tranzacŃii simple şi ramificate, în secvenŃă. Ele sunt cele mai
obişnuite elemente întâlnite în acest tip de diagramă. În special, la modelarea fluxurilor de
producŃie sau la procese de afaceri se pot întâlni fluxuri concurente. În UML se foloseşte o
bară de sincronizare pentru specificarea bifurcărilor şi îmbinărilor. Bara de sincronizare este o
linie orizontală sau verticală groasă, astfel:
229
Culoarele (Swimlanes), uneori apare necesitatea de a împărŃi stările de activitate în

grupuri, fiecare grup reprezentând o organizaŃie responsabilă cu activitatea respectivă.
În UML aceste grupuri se numesc culoare, deoarece vizual fiecare grup este separat de
celelalte grupuri prin bare verticale groase. Fiecare culoar are un nume unic în diagramă,
culoarul reprezintă o entitate din lumea reală.
Culoarul se poate implementa prin una sau mai multe clase. Fluxul de obiecte (Object
flow), obiectele pot fi implicate în fluxul de control asociat cu diagrama de activitate.
Putându-se preciza rolul, starea şi atributele unui flux de obiecte. Diagrama de activitate are
următoarea formă generală (în figura 5.35):
Culoar
Activitate [condiŃie 1] Activitate

[ condiŃie de sincronizare]
[ condiŃie 2]
Obiect Activitate Activitate
Flux de obiecte
Activitate
[ condiŃie 3]
Ramură secvenŃă
[condiŃie 4]
Figura 5.35 Exemplu cu forma generală

În faza de proiectare, diagramele de activităŃi apar ataşate unei clase şi conŃin elemente
de implementare a operaŃiilor descrise în clase. AcŃiunile pot fi descrise în limbaj natural, în
pseudocod sau într-un limbaj de programare (C++, Visual Basic).
Echivalente schemelor logice utilizate în programarea structurată, diagramele de
activităŃi conŃin structurile fundamentale de programare: liniară, repetitivă sau alternativă.
În cazul unei clase cu comportament dinamic semnificativ, pentru cazul în care
modificările de stare au o determinare internă, rezultată din efectuarea sau încheierea unor
operaŃii, starea este descrisă printr-o listă de acŃiuni/activităŃi, ce se execută la apariŃia unui
eveniment.
TranziŃia de la o stare la alta este determinată de încheierea acestor acŃiuni sau
subactivităŃi (tranziŃii interne). În aceste cazuri, diagramele de activităŃi însoŃesc diagramele
de stare.
Punctele de decizie sunt puncte din fluxul de activităŃi în care se face o anumită
alegere între mai multe variante posibile.
Un caz simplu este ilustrat în figura de mai jos.
230
Figura 5.36 Diagramă de activitate cu punct de decizie

Trebuie observat că tranziŃiile care ies dintr-un punct de decizie sunt de tip guard – au
înscrisă între paranteze pătrate o condiŃie. NotaŃia utilizată pentru punctul de decizie poate fi
folosită şi pentru reconectarea fluxurilor (merge point).
AcŃiunile paralele (asincrone) sunt acŃiuni care pot desfăşura în paralel. În viaŃa reală,
aceste acŃiuni sunt acŃiuni care nu depind una de cealaltă. Paralelizarea acŃiunilor se reprezintă
pe diagramă în felul următor:
Figura 5.37 Diagramă de activitate cu activităŃi paralele
231
Această reprezentare ne arată că acŃiunile ”Verificare stoc” şi ”Verificare bonitate

client” sunt declanşate de apariŃia unei comenzi de la client şi că aceste acŃiuni sunt
independenta între ele (începerea uneia nu depinde de rezultatul celeilalte).
Revenirea la fluxul unic (cu acŃiuni sincronizate) se face în felul următor:
Figura 5.38 Revenire la flux unic

Această reprezentare ne arată că livrarea la client depinde de finalizarea acŃiunilor
independente "Verificare stoc" şi "Verificare bonitate client", astfel că acŃiunea "Livrare la
client" nu poate începe decât după finalizarea ambelor acŃiuni.
Pentru a adăuga pe diagrame informaŃia privind responsabilitatea executării acŃiunilor
se folosesc elementele denumite swimlanes, plasându-se fiecare acŃiune pe culoarul actorului
care execută acea acŃiune.
Figura 5.39 Diagramă cu elemente de culoar
232
5.9.4.8. Diagrama de secvenŃă

Diagrama de secvenŃă (DS) este o diagramă de interacŃiune ce subliniază ordinea
mesajelor în funcŃie de timp. Grafic, ea este o tabelă ce arată obiectele (pe axa OX) şi
mesajele ordonate în timp (pe axa OY).
Obiect1 Creare Obiect3
Creare Obiect2
Introducere
Mesaj1 Mesaj3
Punct de
control Distrugere Mesaj4 Iterare
[pentru…] execută() CondiŃie

[condiŃie] execută() Autoreglare
Figura 5.40 Forma generală
DS-ul subliniază ordinea în funcŃie de timp a mesajelor. În realizarea unui DS se

plasează obiectele ce participă la interacŃiune la marginea de sus a diagramei, de-a lungul axei
OX, obiectele care încep interacŃiunea se aşează la stânga, iar obiectele care urmează în
dreapta.
Mesajele se plasează pe axa OY în ordinea timpului, de sus în jos, pentru a putea
vizualiza mai uşor fluxul de control, din punct de vedere al timpului. Ele au următoarele
elemente specifice :
• Linia de viaŃă a obiectului – care este o linie verticală ce reprezintă existenŃa
unui obiect de-a lungul unei perioade de timp. Obiectele apar în DS şi există pe
toată durata interacŃiunii, având linia de viaŃă trasată de la vârful diagramei
până la bază. Liniile de viaŃă pot începe la primirea mesajului “creare”, sau
pentru alte obiecte se termină liniile prin distrugere, ele îşi încheie viaŃa cu
mesajul “distruge”.
• Punctul de control – este un dreptunghi înalt şi subŃire care indică perioada de
timp în care obiectul realizează o acŃiune. Capătul de sus al dreptunghiului este
aliniat la începutul acŃiunii, iar capătul de jos la sfârşitul acŃiunii. În figura 5.39
se redă forma generală a unui DS.
În figura 5.41. se prezintă un exemplu pentru o comandă. Deci mesajele transmise
între obiecte sunt reprezentate prin săgeŃi etichetate cu numele mesajului, la aceste diagrame
intervin şi actori.
În acest sens prezentăm un scenariu de adăugare a unui curs în sistem în figura 5.41.
233
O fereastră de O Comandă O linie de Un element

Introducere comandă de stoc
comandă
Pregăteşte
* [pentru liniile de
comenzi]
Pregăteşte () Există stoc :=
Verifică ()
[există stoc] Cereri recomandă

Înlocuieşte() := Cereri de
Recomandă()
Un element
recomandare
[există stoc ] New Un

element
livrat
Figura 5.41 Exemplu de comandă
Figura 5.42 Adăugarea unui nou curs
234
5.9.4.9. Diagrama de comunicare sau de colaborare (DC)

Ele reprezintă interacŃiunile dintre obiecte organizate relativ la aceasta şi a legăturilor
dintre acestea. Acestea conŃin [4] [7]:
• obiecte ce sunt reprezentate grafic prin dreptunghiuri
• legături între obiecte, reprezentate grafic prin linii de conectare
• mesaje ce sunt reprezentate grafic ca etichetă a legăturilor şi ce conŃine o
săgeată îndreptată spre obiectul server, care este receptorul mesajului
Conform figurii 5.43:
Figura 5.43 Exemplu
Folosind instrumentul Rational Rose se pot genera diagramele de colaborare din

diagrame de secvenŃă (meniu ‘Browse’, comanda ‘Create Collaboration Diagram’) sau invers
(meniu ‘Browse’, comanda ‘Create Sequence Diagram’).
ObservaŃii:
De ce sunt utilizate două diagrame echivalente ca putere de modelare, dar diferite din
punct de vedere notaŃional?' Diagramele de secvenŃă oferă o imagine temporală a scenariului.
Ele sunt uşor de ‘citit’ şi înŃeles de către client sau utilizatorul final.
De asemenea sunt utile în fazele timpurii ale analizei pentru identificarea obiectelor şi
claselor. Deoarece diagramele de colaborare surprind legăturile dintre obiecte, acestea sunt
utile la faza de proiectare, atunci când se modelează implementarea relaŃiilor.
Diagrama de colaborare arată organizarea obiectelor ce participă la interacŃiune.
Acestea sunt plasate primele ca vârfuri ale unui graf, se trasează legăturile care conectează
obiectele, ca arce în acest graf, apoi se adaugă acestora legături, mesaje pe care obiectele le
primesc sau transmit.
Ea conŃin două elemente specifice [44]:
• calea – pentru a arăta faptul că un obiect este legat cu un altul, trebuie să fie o
cale (local, parametru, global sau self);
• numărul de secvenŃă – arată ordinea, mesajul trebuie prefixat cu un număr,
începând de la unu crescător.
Forma generală a digramei este dată de următoarea figură (5.43):
235
Obiect_1
Autoreglare
1 : << creare >>
<< local >> 2 : <<mesaj >>
Legătură 3 : << distrugere >>
<<global >>
Obiect_2 Obiect_3
2.1. mesaj
Număr secvenŃă 2.2. [ condiŃie mesaj] Mesaj
Figura 5.44 Cu exemplu general
În continuare dăm un exemplu de DC pentru o comandă (figura 5.44)

Fereastră
Introduce
Comandă 1 : pregătire()
Comandă
2 : * [pentru toate liniile de comandă] pregăteşte()
3 : există stoc := verifică
4 : [există stoc] := înlocuieşte
5 : cereriRecomandă := cereredeRecomandă()
Linie Linie
comandă comandă
7 : [există stoc] := New 6 : [cereriRecomandă] := New
Element Recomandat
Element livrare
Figura 5.45 Exemplu de diagramă de colaborare
Deşi cele două diagrame (DS, DC) sunt echivalente, putându-se converti una din alta
fără pierderi informaŃii, asta nu înseamnă că cele două diagrame pun în evidenŃă aceleaşi
aspecte. DC -ul arată cum sunt legate obiectele (local sau global), în timp ce DS-ul pune în
evidenŃă şi mesajele returnate.
5.9.4.10. Diagrama maşinilor de stare

În UML hărŃile de stări sunt utilizate în descrierea comportamentului obiectelor
aparŃinând unui clase. O stare (concretă) este caracterizată de valorile proprietăŃilor unui
obiect şi de mulŃimea mesajelor care pot fi acceptate de către acest obiect la un moment dat. O
stare conŃine descrierea unui invariant de stare (condiŃie logică adevărată pentru toate
obiectele care se află în starea respectivă), şi a trei proceduri speciale: entry, exit şi do. Aceste
proceduri descriu secvenŃele de acŃiuni care vor fi executate în momentul în care un obiect
intră (entry), părăseşte (exit) sau se află (do) în starea respectivă.
O stare se reprezintă grafic prin intermediul unui dreptunghi cu colŃurile rotunjite,
afişând în partea superioară un nume de stare. În partea inferioară a dreptunghiului opŃional
poate exista un compartiment care conŃine expresiile ce definesc invariantul de stare şi cele
trei proceduri speciale.
236
O tranziŃie exprimă o situaŃie în care un obiect poate trece dintr-o stare în alta.
TranziŃiile se reprezintă grafic prin intermediul unor arce de cerc, linii simple sau linii
poligonale orientate şi (opŃional) etichetate care unesc două stări, numite stare sursă, respectiv
destinaŃie.
Eticheta unei tranziŃii este formată dintr-o signatură de mesaj, o condiŃie (expresie
logică) şi o secvenŃă de activităŃi care au loc în momentul declanşării tranziŃie. Pentru un
obiect oarecare o tranziŃie este declanşată atunci când obiectul se află în starea sursă a
acesteia, execută operaŃia corespunzătoare mesajului şi este îndeplinită condiŃia specificată în
etichetă.
HărŃile de stări permit reprezentarea ierarhică a stărilor unui obiect prin intermediul
stărilor compuse (întâlnite şi sub denumirea de XOR – stări, stări abstracte sau super-stări).
Stările compuse conŃin un număr finit de stări simple sau compuse. Un obiect aflat într-o stare
compusă se va afla în una şi numai una din substările acesteia.
Stările compuse se reprezintă grafic la fel ca stările simple, la care se adaugă un
compartiment special, localizat între numele stării şi compartimentul destinat afişării
invarianŃilor de stare şi a procedurilor speciale. În cadrul acestui compartiment sunt
reprezentate grafic toate substările corespunzătoare.
Diagramele de tranziŃie a stărilor arată o maşină de stare. Acestea sunt utile în
modelarea ciclului de viaŃă a unui obiect. Ele se pot ataşa claselor, cazurilor de utilizare sau a
întregului sistem, ca să vizualizăm, să specificăm şi să documentăm aspectele dinamice ale
acestora.
Maşina de stări este un comportament ce specifică secvenŃa de stări prin care trece un
obiect, pe parcursul vieŃii sale, ca răspuns la evenimente.
Starea este o condiŃie sau o situaŃie în viaŃa unui obiect, când acesta satisface anumite
activităŃi sau aşteaptă anumite evenimente.
Evenimentul reprezintă specificarea unei operaŃii semnificative care are o locaŃie în
timp şi spaŃiu.
Activitatea este o execuŃie nonatomică în derulare într-o maşină de stare.
AcŃiunea este o operaŃie atomică, executabilă ce duce la schimbarea unei stări sau
returnează o valoare.
DTS –ul conŃine în mod obişnuit stările simple şi compuse, precum şi tranziŃii,
inclusiv evenimente şi acŃiuni.
DTS –ul în esenŃă este o proiecŃie a elementelor ce sunt într-o maşină stare.
Maşina de stare este un comportament ce specifică secvenŃa de stări prin care trece un
obiect pe parcursul vieŃii sale, ca răspuns la evenimente, împreună cu răspunsul lor la
evenimente. Ele sunt folosite la modelarea aspectelor dinamice ale sistemului.
Maşina cu stări modelează un sistem obiect, fie că este instanŃă a unei clase, un caz de
utilizare, sau chiar întregul sistem.
Maşinile de stare se pot vizualiza în două moduri [30]:
• folosind diagramele de activitate, unde se concentrează pe activităŃile ce au loc
în obiect;
• folosind diagramele de stare, unde ne concentrăm pe comportamentul ordonat
de evenimente ale obiectului.
Elementele unui DTS, se descriu şi se reprezintă astfel:
Starea, care se compune din:
• nume – dar poate fi şi anonimă;
• acŃiune de intrare/ieşire – care se execută la intrarea sau ieşirea din stare;
• tranziŃii interne – care se realizează fără a căuta o schimbare de stare;
• substări – structura imbricată a unei stări implică substări disjuncte sau
concurente;
237
• evenimente amânate – sunt recunoscute de stare, dar puse într-o coadă ca să

fie rezolvate de obiect într-o altă stare.
Starea iniŃială arată locul implicit de start pentru o maşină de stare sau substare.
Starea finală arată execuŃia unei maşini de stare sau faptul că starea de finalizare a fost
completă.
În momentul schimbării unei stări se poate spune că are loc o tranziŃie. Până când
tranziŃia are loc obiectul este într-o stare sursă, iar după ce tranziŃia are loc este într-o stare de
destinaŃie.
TranziŃia are cinci părŃi, anume [30]:
• stare sursă
• eveniment declanşator – a cărui receptare de către obiect face posibil să aibă
loc evenimentul, asigurând satisfacerea condiŃiilor. Evenimentele pot fi
semnalmente, apeluri, trecerea timpului, schimbarea de stare
• condiŃii – ce sunt o expresie booleană care este evaluată când are loc tranziŃia,
iar dacă are valoare de adevăr, tranziŃia poate avea loc. Ea se evaluiază odată
pentru fiecare tranziŃie, în momentul când are loc evenimentul, dar se poate
evalua din nou dacă tranziŃia se repetă
• acŃiunea – este o operaŃie atomică executabilă, ce poate acŃiona direct asupra
obiectului care deŃine maşina de stări şi indirect altor obiecte care sunt vizibile
obiectului. Ea poate include apeluri de operaŃii, crearea şi distrugerea unui alt
obiect sau trimiterea unui semnal unui obiect
• starea de destinaŃie
Forma generală a unei diagrame de stare este:
eveniment
Stare Stare Stare
control
Stare Stare
Stări şi tranziŃii avansate

1) AcŃiuni de intrarea ieşire – ce se folosesc când se doreşte ca aceeaşi acŃiune să aibă
loc ori decâte ori se intră într-o stare sau se părăseşte starea, indiferent de tranziŃia ce
conduce la acea stare. În schimbul stării se va include în acest caz o acŃiune de intrare
(ce este prezentată cu cuvântul cheie entry), respectiv o acŃiune de ieşire (marcată cu
cuvântul cheie exit).
2) TranziŃii interne – ce se foloseşte atunci când de doreşte rezolvarea unor evenimente
fără a părăsi starea. Ele sunt subtil deferite de tranziŃiile spre sine. Într-o tranziŃie spre
sine, un eveniment declanşează o tranziŃie, se părăseşte starea, evenimentul are loc, o
acŃiune şi apoi se reintră în acea stare, deci se realizează acŃiunea de ieşire, acŃiunea
tranziŃiei şi apoi acŃiunea de intrare în starea respectivă.
3) ActivităŃi – când obiectul este într-o stare, în general rămâne inactiv, aşteptând
apariŃia unui eveniment. Alteori, aflat într-o stare, un obiect va realiza o sarcină şi o va
continua până când este întrerupt de un eveniment. UML–ul foloseşte pentru această
tranziŃie specială pe do. Se poate specifica şi o secvenŃă de acŃiuni, exemplu:
do(op1(a);op2(b);op3(c)).
4) Evenimente amânate – în unele situaŃii de modelare se doreşte recunoaşterea unor
evenimente, dar amânarea răspunsului la acestea. El este o listă de evenimente a căror
238
operaŃie în stare se amânată până când devine activă starea în care evenimentele
acestea nu sunt amânate, moment în care ele se declanşează şi pot conduce la o
tranziŃie, ca şi cum atunci s-ar fi întâmplat. Acesta se realizează cu acŃiunea specială
defer.
Grafic se reprezintă astfel:
Nume stare
AcŃiune de intrare Entry/acŃiune(parametru)
AcŃiune de ieşire Exit/acŃiune(parametru)
Eveniment amânat AcŃiune/defer
Activitate Do/
TranziŃie interioară AcŃiune/acŃiune
Substări
Aceasta este o stare imbricată într-o altă stare. Starea ce are substări se numeşte stare
compusă şi poate conŃine substări secvenŃiale sau concurente.
1) Substări secvenŃiale sau disjuncte
Fiind dat un set de stări secvenŃiale, obiectul se află în starea compună şi doar într-una
din stările sale la un moment dat. O tranzacŃie dintr-o altă stare poate avea ca Ńintă o stare
compusă sau o substare a acesteia.
Dacă Ńinta este o stare compusă, atunci maşina cu stări din interiorul să trebuie să
conŃină o stare iniŃială. În cazul că Ńinta este o substare, atunci controlul îi este predat acesteia,
după execuŃia acŃiunii de intrare pentru starea compusă şi o acŃiune de intrare pentru substare.
O tranziŃie ce conduce la ieşirea dintr-o stare compusă poate avea ca sursă starea
compusă sau o substare a acesteia, conform figurii: ce ne arată tranziŃie din/în stare compusă,
Stare compusă
Stare Entry/acŃiune
Entry/acŃiune
tranziŃie cancel
Stare
Substare
Stare
Substare [condiŃie]
Substare
tranziŃie din substare
Figura 5.46 Exemplu general
2) Substări concurente
Acestea specifică două sau mai multe maşini de stare ce se execută în paralel, în
contextul obiectului ce-l include. Date fiind două sau mai multe substări concurente la acelaşi
nivel, un obiect va fi într-o stare secvenŃială din fiecare din stările concurente. O maşină de
stare imbricată concurentă nu are stare iniŃială sau finală.
În continuare să vedem exemplul cu aplicaŃia web:
239
Figura 5.47 Diagrama de stare a aplicaŃiei web
5.9.4.11. Diagrama de componente

Ele prezintă dependenŃele existente între diverse componente soft ce compun un sistem
informatic. Aceste dependenŃe sunt statice sau dinamice.
Componenta are un model soft cu o interfaŃă bine definită. Un tip de componentă
reprezintă o parte distinctă, realocabilă a implementării sistemului.
InstanŃa unei componente este o unitate de implementare în execuŃie şi poate fi utilizată
la reprezentarea unităŃilor de implementare ce au o identitate în momentul execuŃiei.
Reprezentarea grafică a componentei este:
Componenta
: tip com ponenta
Figura 5.48 Diagrama de componente
Tipul de componentă are asociat un nume, iar o instanŃă a unei componente are
asociate (opŃional) un nume şi un tip. Numele componentei va fi numele fişierului ataşat
acesteia.
Obiectele implementate de o instanŃă de componentă se reprezintă grafic în interiorul
simbolului instanŃei de componentă. Analog se reprezintă grafic clasele implementate în
componente. Digrama de componente este un graf de componente între care există relaŃii de
dependenŃă sau compunere.
DependenŃele între componente se reprezintă grafic prin linii întrerupte între o
componentă client şi o componentă furnizor de servicii, orientat spre componenta furnizor.
RelaŃie de dependenŃă semnifică faptul că clasele incluse în componentă pot fi moşteniri,
instanŃe sau clase în componenta furnizor. O diagramă ce conŃine tipuri de componente poate
fi utilizată la reprezentarea de dependenŃe statice, cum este dependenŃa de compilare între
diverse programe, conform figurii 5.49.
240
Pot exista relaŃii de dependenŃă între componente şi interfeŃe ale altor componente,
relaŃii ce semnifică faptul că clientul utilizează operaŃii ale componentei server, conform
figurii 5.49.
Compunerile se reprezintă grafic prin încuibărirea simbolurilor asociate obiectelor
sau claselor în cadrul simbolurilor unei componente.
Instrumentul Rational Rose introduce o serie de stereotipuri predefinite pentru
componente, astfel [4] [10]:
• programe principale (<< Main Program >>)
• subprograme (<< Subprogram >>)
• pachete (<< Package >>)
• librării cu legendă dinamică (<< DLL >>)
• procese (<< Task >>)
• executabile (<< Exe >>)
Ele (DC) reprezintă un alt fel de diagrame utilizat în modelarea aspectelor fizice ale
sistemelor orientate obiect. Acestea ne arată organizarea şi dependenŃele din cadrul unui set
de componente. Ele se folosesc la modelarea viziunii asupra implementării statice a unui
sistem.
Acestea implică modelarea elementelor fizice care pot exista într-un nod, cum ar fi
programele executabile, biblioteci, tabele, fişiere şi documente. Ele sunt diagramele claselor
esenŃiale ce se orientează pe componentele unui sistem. Acestea nu sunt importante doar
pentru vizualizare, ci şi pentru construirea sistemelor executabile prin ingineria directă şi
inversă.
Figura 5.49 DependenŃe statice şi două reprezentări grafice alternative a componentelor

în Rational Rose
241
Diagrama de componente descrie un set de componente şi relaŃiile dintre ele, iar grafic,
este o colecŃie de noduri şi arce, fiind de fapt o diagramă mai specială, având aceleaşi
proprietăŃi ca şi alte diagrame, un nume şi un conŃinut grafic. Are un conŃinut particular,
având componente, interfeŃe şi relaŃii de dependenŃă, generalitate, asociere şi realizare.
Mai poate conŃine note, reguli, pachete sau subsisteme, în interiorul cărora se pot plasa
instanŃe. Ea se foloseşte cu unul din scopurile [30]:
• La modelarea codului sursă, cu limbajele de programare curente, ce stochează
codul sursă în fişiere. Cu acestea se modelează managementul configurării acestor
fişiere.
• La modelarea produselor executabile. Un produs executabil se focalizează prin
părŃi necesare pentru furnizarea sistemului în lucru. Aici se vizualizează, specifică
şi documentează deciziile referitoare la părŃile fizice care formează softul.
• La modelarea bazei de date fizice, care înseamnă stocarea informaŃiilor în tabelele
unei baze de date relaŃionale sau pe paginile unei baze de date orientate obiect.
• La modelarea sistemelor adaptabile, unele sisteme sunt statice, altele sunt
dinamice, având componente mobile care migrează în funcŃie de schimbările
apărute.
Figura 5.50 DependenŃe dinamice între componentele unui sistem informatic de

gestiune a biletelor de călătorie cu avionul
Forma lor generală este urătoarea (având componentele necesare), în figura 5.51:
Nume fişier Nume fişier Nume fişier
Nume fişier Nume fişier
Nume fişier Nume fişier
Figura 5.51 Forma generală
242
5.9.4.12. Diagrama de desfăşurare sau de exploatare (DE)

Diagramele de desfăşurare sau de exploatare prezintă configuraŃia elementelor de
procesare din timpul execuŃiei şi componentele, procesele şi obiectele care le conŃin. Fiecare
model al unui sistem informatic are asociată o singură diagramă de exploatare.
InstanŃele componentelor soft reprezintă manifestări a unor unităŃi de cod în cadrul
execuŃiei. Componentele care nu există ca entităŃi de execuŃie nu apar în aceste diagrame, ci
doar în diagramele de componente. O diagramă de exploatare este un graf de noduri conectate
prin asocieri de comunicare. Nodurile pot conŃine instanŃe ale componentelor. Componentele
pot conŃine obiecte. Componentele sunt conectate cu alte componente sau interfeŃele acestora
prin intermediul unor relaŃii de dependenŃă (săgeŃi întrerupte) ceea ce reprezintă faptul că o
componentă foloseşte serviciile altei componente.
Pot fi utilizate stereotipuri pentru a preciza în detaliu tipul dependenŃei dintre
componente. Un nod este o entitate fizică ce reprezintă o resursă de procesare, având o
memorie şi anumite capabilităŃi de procesare (dispozitive de calcul, resurse umane, resurse de
procesare mecanică).
Un nod este reprezentat grafic prin intermediul unui paralelipiped. Un tip de nod are
asociat un nume, iar o instanŃă a unui nod are asociate (opŃional) un nume de instanŃă şi un
nume de tip (nume instanŃă : nume tip). O asociere între două noduri indică existenŃa unei căi
de comunicare între noduri. Asocierea poate avea un stereotip care să indice tipul de
comunicare (tipul de canal, reŃea).
Diagramele de exploatare pot fi utilizate pentru reprezentarea componentelor ce pot
aparŃine anumitor noduri. Această relaŃie se reprezintă grafic prin intermediul unei linii
întrerupte între un nod şi o componentă, având stereotipul <<support>> sau prin
‘încuibărirea’ grafică a simbolului componentei în cadrul simbolului ce reprezintă nodul.
Figura 5.52 Diagrama de exploatare pentru o aplicaŃie de gestiune a biletelor de călătorie cu

avionul
Migrarea instanŃelor de componente dintr-un nod în altul, sau migrarea obiectelor de
la o componentă la alta poate fi implementată grafic utilizând stereotipul <<become>> ataşat
relaŃiei de dependenŃă. În această situaŃie instanŃa componentei/obiectul vor aparŃine unei
instanŃe a unui nod/unei instanŃe de componentă doar o perioadă de timp din ciclul lor de
viaŃă.
243
Procesoarele reprezintă componente hard capabile să execute programe. La nivelul

fiecărui procesor pot fi identificate procese şi modul de planificare al acestora (preemptiv,
non-preemptiv, ciclic, prin intermediul unui algoritm particular sau manual).
În aceste diagrame, procesele reprezintă fire de execuŃie distincte (ex. programul
principal, sau obiecte active).
Figura 5.53 Reprezentarea grafică a procesoarelor în Rational Rose

Dispozitivele reprezintă componente hard fără putere de calcul. Numele asociat unui
dispozitiv este în general unul generic (ex. imprimantă, modem, terminal etc). O conexiune
reprezintă o legătura hard (în general bidirecŃională) între două dispozitive sau procesoare.
5.10. Baze de date relaŃionale în context obiectual

Pentru reprezentarea şi modelarea bazelor de date sunt folosite multe tipuri de
diagrame. În acest capitol ne ocupăm cu modelarea bazelor de date utilizând UML (Unified
Modelling Language). UML este un limbaj de vizualizare, specificare, construire şi
documentare a modelelor.
Oficial în UML nu există diagrame pentru modelare de date, dar avem un sistem de
notare şi modelare pentru date, utilizat şi acceptate de multe instrumente CASE. Această
notare folosită pentru modelarea datelor în UML provine din diagramele de clase şi alte
sisteme de notare folosite în modelul clasice (entitate-relaŃie).
5.10.1. Diagrama pentru modelarea datelor

Diagrama de modelare a datelor formal este o diagramă de clasă în UML. Tabele sunt
clasele, câmpurile sunt atribute şi relaŃiile sunt tot relaŃii. La tabele folosim stereotipul
<<Table>> şi la câmpuri stereotipul <<Column>>.
Exemplu:
Maşină
*PK ID : Counter
* Cod : Integer
Denumire : Text(15)
Numar : Text(10)
Culoare : Text(12)
«PK» PK_Masina()
Figura 5.54 Tabelul Maşină
244
Baze de date relaŃionale în context obiectual
NotaŃia de mai sus este modelul folosit în Enterprise Architect, dar şi în alte
instrumente CASE este asemănător.
În cazul tabelelor vizibilitatea nu este definită sau putem spune că implicit este public.
Câmpurile care nu pot avea valoarea NULL (NOT NULL) sunt notate cu *.
Desigur între tabele pot exista relaŃii, cum sunt şi în cazul tabelelor relaŃionale, dar cu
aceste cazuri ne ocupăm mai târziu.
5.10.2. Comportamentul tabelelor

Deşi tabelele din modelul relaŃional nu au la propriu zis un comportament în context
obiectual, totuşi pe diagramă sunt definite metode.
Pe diagrama bazei de date sunt folosite următoarele notaŃii [32]:
NotaŃie Descriere
«PK» Cheie unică.
«FK» Cheie străină.
«unique» Constrângere la unicitate.
«check» Alte constrângeri.
«index» Index.
«trigger» Trigere.
«proc» Proceduri.
Dacă folosim diagramele de clase clasice tabelele vor deveni tot clase, iar câmpurile
metode [18].
5.10.3. Două orientări diferite

Sunt bine cunoscute proprietăŃile paradigmei orientate-obiect: încapsulare, moştenire
şi polimorfism. Toate aceste proprietăŃi sunt programate procedural, adică descriem efectiv
paşii necesari.
În lume relaŃională instrucŃiunile nu sunt de tip procedural, ci sunt orientate pe
rezultat. Nu sunt cunoscute nici încapsulare, nici protejarea informaŃiilor şi nici moştenirea.
Lumea relaŃională cunoaşte foarte bine comanda select, cu ajutorul căreia sunt
interogate bazele de date. Toate elementele unei dezvoltări de aplicaŃii sunt prezente atât în
modelul relaŃional, cât şi în modelul obiectual.
În cadrul implementării de multe ori suntem nevoiŃi să îmbinăm programarea
obiectuală cu baze de date relaŃionale.
Dar înainte de implementare analiza, modelare business, proiectarea poate fi realizat
cu orientarea dorită, adică clasic sau obiectual.
În cadrul acestei lucrări ne ocupăm cu analiza, modelarea şi proiectarea obiectuală.
De multe ori este necesar să comparăm dezvoltarea aplicaŃiilor orientate-obiect cu
gestionarea relaŃională a bazelor de date.
Următorul tabel conŃine comparaŃia modelului relaŃional cu cel obiectual [32].
245
Paradigma OO RDBMS
Element de bază Obiecte, clase. MulŃime (tabele).
CorespondenŃă Obiect = înregistrarea unui tabel DefiniŃie tabel = clasă
Clasă = metadatele unui tabel Tabel concret = container
Înregistrare = obiect
Programare Procedural. Orientat către rezultat .
Extensibilitatea Da, cu definirea unor clase noi. Nu, este imposibil definirea
limbajului unor noi operaŃii.
PersistenŃă Nu, sau forte constrâns. Da.
Gestionarea Posibil. Da, este optimizat pe acesta.
mulŃimilor de datelor
Încapsulare Da, concept de bază. Nu, codul şi datele nu sunt
într-un loc.
Vizibilitatea Implicit privat. Implicit public.
informaŃiilor
Moştenire Da, concept de bază. Nu este.
Durată de viaŃă Tranzient. Persistent.
Topologie ReŃea. Tabele (relaŃii).
5.10.4. CorespondenŃa clasă-tabel

În modelul obiectul clasele arată în felul următor (instrumentul case Rational Rose):
Materiale
CodMateri al : Long
DenumireMaterial : String
UnitateMasura : String
Figura 5.55 Clasa Materiale

Clasa Materiale devine tabelul Materiale şi se poate modela în felul următor:
Materiale
PK CodMaterial : NUMBER
DenumireMaterial : VARCHAR2
UnitateMasura : CHAR
<<PK>> PK_Material13()
Figura 5.56 Tabelul Materiale
246
După cum putem vedea clasele devin tabele, atributele câmpuri şi această regulă este
valabilă şi în sens invers, adică tabele devin clase.
5.10.5. Asocieri între tabele

În modelul relaŃional sunt cunoscute următoarele asocieri (legături) între tabele:
• asociere de tip 1-1
• asociere de tip 1-n
• asociere de tip m-n
5.10.5.1. Asociere de tip 1-1

În cazul asocierilor de tip 1-1 unei entităŃi din mulŃimea sau clasa M1 îi corespunde
cel mult o singură entitate în mulŃimea sau clasa M2.
În exemplu la o secŃie poate fi cel mult un angajat. Diagrama de clasă este următoarea:
Angajat
Sectie
CodAngaj at : Long
CodSectie : Long
NumeAngajat : String
1 1
Figura 5.57 Clasele Angajat şi Sectie

În context relaŃional modelat cu UML tabelele vor fi:
Angajat Sectie
PK CodAngajat : NUMBER <<Non-Identyfing>> PK CodSectie : NUMBER

NumeAngajat : VARCHAR2 FK CodAngajat : NUMBER
1 0..1
<<PK>> PK_Angajat34() <<PK>> PK_Angajat35()

<<FK>> FK_Angajat37()
Figura 5.58 Tabelele Angajat şi SecŃie
5.10.5.2. Asociere de tip 1-n

În cazul asocierilor de tip 1-n unei entităŃi din mulŃimea sau clasa M1 îi corespund mai
multe entităŃi în mulŃimea sau clasa M2, iar unei entităŃi din M2 îi corespunde o singură
entitate în M1. În exemplul următor unui obiect îi sunt asociate mai multe obiecte ordonate.
Diagrama de clasă este următoarea:
Obiect
CodObiect : Long ObiectOrdonat
Descriere : String CodOrdonat : Integer
Pret : Double 1 0..*
Figura 5.59 Clasele Obiect şi ObiectOrdonat
247
În context relaŃional modelat cu UML tabelele vor fi:
Obiect ObiectOrdonat
PK CodObiect : NUMBER <<Non-Identyfing>> PK CodOrdonat : NUMBER

Descriere : VARCHAR2 FK CodObiect : NUMBER
Pret : NUMBER 1 0..*
<<PK>> PK_ObiectOrdonat10()
<<PK>> PK_Obiect13() <<FK>> FK_ObiectOrdonat20()
Figura 5.60 Tabelele Obiect şi ObiectOrdonat
5.10.5.3. Asociere de tip n-m

În cazul asocierilor de tip n-m unei entităŃi din mulŃimea sau clasa M1 îi corespund
mai multe entităŃi în mulŃimea sau clasa M2, iar unei entităŃi din M2 îi corespund mai multe
entităŃi în M1. În exemplul următor un client cunoaşte mai mulŃi vânzători şi invers. Diagrama
de clasă este următoarea:
Cumparator Vanzator
CodCump : Long CodVanzator : Long
Num e : String Num e : String
0..* 0..*
Figura 5.61 Clasele Cumpărător şi Vânzător

După cum se vede şi din exemplul de mai sus, în context obiectul se poate modela o
asociaŃie de tip n-m doar cu două clase. Pentru reprezentarea asociaŃiei de tip n-m în context
relaŃional avem nevoie şi de un tabel intermediar (suplimentar), care are ca şi atribute cheile
celor două relaŃii. Desigur putem avea şi alte atribute. Cheia în această nouă relaŃia de obicei
este o cheie compusă din cele două atribute care provin din cele două tabele.
În context relaŃional modelat cu UML tabelele sunt: Cumpărător, Vânzător şi
CumpVanzator.
În exemplul de mai jos în tabela CumpVanzator avem a cheie compusă din două
atribute: CodVanzator şi CodCump.
5.10.6. Obiecte persistente

Etapa de proiectare a unei aplicaŃii presupune şi determinarea obiectelor persistente,
adică a acelor obiect ce se vor păstra între două execuŃii ale unei aplicaŃii.
Determinarea acestor obiecte se realizează pe baza diagramei de clase, după care ele
sunt translatate într-un model relaŃional ce va stă la baza proiectării bazei de date.
Cea mai simplă şi uşoară metodă de translatare a claselor în tabele ale unei baze de
date este asocierea 1:1 a claselor cu tabele.
Această metodă nu este însă recomandată deoarece pot apărea următoarele probleme:
• prea multe tabele – în general din modelele OO pot rezulta, prin această
metodă, mai multe tabele decât este necesar
248
• prea multe operaŃii de conectare (join) – multe tabele => mai multe operaŃii
de join SQL pentru regăsirea datelor (relaŃiile de 1:1)
• tabele ignorate – relaŃiile de asociere n:m se implementează prin intermediul
unei tabele de legătură. Clasele asociere reduc aceste probleme, dar ele sunt în
puŃine cazuri modelate
• tratarea necorespunzătoare a moştenirii
• de-normalizarea datelor - duplicarea aceloraşi date în mai multe tabele (apare
în special din cauza claselor care modelează necesităŃi unice de raportare).
Cazurile de utilizare / diagramele de interacŃiune pot da anumite informaŃii legate de
frecvenŃa de utilizare / interogare a anumitor date => încercare de proiectare a bazei de date
astfel încât aceste operaŃii să se realizeze într-un minim de timp.
Înainte de a transforma clasele în entităŃi relaŃionale trebuie să răspundem la
întrebarea: Dacă necesită să fie persistentă sau nu?
Cumpărător Vânzător
PK CodCump : NUMBER PK CodVanzator : NUMBER

Nume : VARCHAR2 Nume : VARCHAR2
<<PK>> PK_Cumparator26() <<PK>> PK_Vanzator30()
1 1
<<Identifying>> <<Identifying>>
0..* 0..*
CumpVanzator
P/FK CodVanzator : NUMBER

P/FK CodCump : NUMBER
<<PK>> PK_231()
<<FK>> FK_233()
<<FK>> FK_232()
<<Index>> TC_265()
<<Index>> TC_264()
Figura 5.62 Tabelele Cumpărător, Vânzător şi CumpVanzator
5.10.6.1. Transformarea relaŃiei de moştenire

Exista trei variante de transformare in tabele a unei perechi superclasă / subclasă,
anume [32]:
1. Se creează câte o tabelă pentru fiecare clasă şi un view SQL pentru fiecare
pereche superclasă / subclasă.
249
2. Se creează o singura tabelă (corespunzătoare superclasei) şi se de-normalizează

toate coloanele de informaŃii din subclase în tabela superclasei. Implică
modificări ale tabelei pentru următoarele subclase, şi conŃine spaŃii ‘moarte’
=> poate afecta performanŃa accesului la date. Se mai adaugă un câmp (şi
eventual o tabelă) special care precizează tipul unei înregistrări memorate în
tabelă.
3. Se creează câte o tabelă pentru fiecare subclasă şi se de-normalizează atributele
superclasei în fiecare subclasă. Dacă se modifică superclasa, trebuie să se
modifice toate subclasele.
Exemplu (persoană şi profesor):
Profesor
Persoana
catedra : String
nume : String
salar : Int
prenume : String
nrore : Int
eMail : String
functie : String
Figura 5.63 Clasele Persoană şi Profesor

În context relaŃional modelat cu UML tabelele sunt:
Persoană
PK ID : COUNTER
nume : VARCHAR2
prenume : VARCHAR2
eMail : VARCHAR2
<<PK>> PK_Persoană(COUNTER)
0..1
Profesor
PK CNP : NUMBER
catedra : VARCHAR2
salar : NUMBER
nrore : NUMBER
functie : VARCHAR2
<<PK>> PK_Profesor()
<<FK>> FK_Profesor_Persoana()
Figura 5.64 Tabelele Persoana şi Profesor
250
În cazul în care numărul înregistrărilor este limitat în superclasă şi subclase atunci

prima variantă este cea mai potrivită (performanŃa nu este grav afectată, iar flexibilitatea este
maximă).
Dacă numărul atributelor în superclasă este mic în comparaŃie cu subclasă atunci
varianta 3 este una acceptabilă. În fine, în cazul în care cantitatea de date din subclase este
mică atunci varianta 2 reprezintă o soluŃie de compromis acceptabilă deoarece performanŃa de
acces la date este cea mai bună însă cu un potenŃial redus de flexibilitate.
Evident, oricare va fi decizia de transformare a unei relaŃii de moştenire, nivelul de
logică a aplicaŃiei nu va fi afectat, deoarece aici se vor vedea entităŃile aşa cum sunt în
diagrama de clase.
Doar frazele SQL (nivelul de translatare a cererilor de la nivelul de logică a aplicaŃiei)
vor fi afectate.
5.10.6.2. Transformarea agregării şi compunerii

RelaŃiile de agregare se implementează în tabele separate fără ştergere în cascadă. De
obicei în aceste cazuri se formează multe relaŃii 1:1.
Exemplu (carte şi autori):
Carte +autor Persoana
isbn : String
nume : String
titlu : String 1..*
{ordered}
Figura 5.65 Clasele Carte şi Persoana
În context relaŃional modelat cu UML tabelele sunt:
Persoana
Carte
PK ID : COUNTER
PK isbn : VARCHAR2 1 0..1 FK isbn : VARCHAR2
nume : VARCHAR2
titlu : VARCHAR2
functie : VARCHAR2
<<PK>> PK_Carte() <<PK>> PK_Persoana(COUNTER)

<<FK>> FK_Persoana_Carte()
Figura 5.66 Tabelele Carte şi Persoana

RelaŃiile de compunere sunt implementate aproape întotdeauna ca o singură tabelă.
Atunci când se alege varianta cu mai multe tabele, atunci trebuie implementată opŃiunea de
ştergere în cascadă.
Asocierile reflexive se transformă în relaŃii recursive. Acestea sunt dificil de întreŃinut,
mai ales în cazul asocierilor bidirecŃionale care au asociate constrângeri de integritate.
251
Exemplu (maşină şi motor):

Masina
Motor
numar : String
nrmotor : String
anfab : Int
volum : Int
nrcaroserie : String 1 1
Figura 5.67 Clasele Maşină şi Motor
În context relaŃional modelat cu UML tabela este:
Maşina
PK ID : COUNTER
numar : VARCHAR2
anfab : NUMBER
nrmotor : VARCHAR2
volum : NUMBER
<<PK>> PK_Masina(COUNTER)
Figura 5.68 Tabela Maşina

Cheile asociate tabelelor pot fi naturale sau surogat, generate automat de către sistemul
de gestiune al bazelor de date. Avantaje pentru a doua abordare:
• toate cheile din baza de date sunt de acelaşi tip – viteză în join-uri şi
consistenŃă
• join-uri limitate la un singur câmp (în locul unei chei compuse)
• necesarul de stocare este redus
Dezavantajele folosirii Rational Rose pentru generarea de tabele din diagramele de
clase [4] [10] [32]:
• dacă anumite atribute nu se generează (din cauza unor erori), atunci trebuie
făcută adăugarea manual
• nu se generează tabele de intersecŃie pentru asocieri n:m (doar dacă este o clasă
asociere)
• pentru două clase A şi B aflate într-o asociere 1:n bidirecŃională se generează 2
relaŃii distincte între tabelele corespunzătoare claselor A şi B
• nu suportă atribute tranzitorii (calcule, etc.). Ele vor fi generate în tabele.
5.10.7. Modelarea şi proiectarea bazelor de date
5.10.7.1. Modelarea bazelor de date

Modelarea bazelor de date se bazează mai mult pe modele logice şi fizice ale bazelor
de date. Un model logic al unei baze de date este compus din entităŃi, atribute şi conŃine
relaŃiile dintre entităŃi care pot fi obligatorii sau nu [18].
Modelul logic este un model standardizat, care este în forma normală 3 (3NF). Poate
conŃine mai multe elemente, care se află lângă baza de date, dar nu conŃine nimic specific
unui software sau unui sistem de gestiune a bazelor de date.
252
În acest caz nu este important factorul de optimizare, nici aplicaŃia în care va fi

gestionat baza de date. În centru se află construirea modelului. Procesul de de-normalizare
începe cu modelul bazei de date fizice. Grupul de programatori încearcă să optimizeze
modelul şi să încerce implementarea acestuia.
5.10.7.2. Proiectarea bazelor de date

Până când modelarea pune accent pe prezentarea bazei de date, proiectarea conŃine
întregul proces care începe cu specificarea, continuă cu modelarea business, analiza logică,
structura fizică a bazei de date până la implementarea şi instalarea acestuia.
De exemplu la proiectarea bazei de date în cadrul modelării fizice sunt deja precizate
tabele, coloanele şi pe lângă acestea şi modelarea hardware, respectiv structura sistemului de
baze de date.
Proiectarea bazei de date conŃine [18]: cerinŃele de modelare, procese business (care
pot fi astăzi sau în viitor), activităŃi business, modele logice, modelul bazei de date fizice,
legăturile între bază de date şi aplicaŃiei, realizarea sistemului.
După proiectare urmează implementarea propriu zisă, care poate fi realizat individual
sau în cele mai multe cazuri în grup.
5.10.7.3. Diagrame UML pentru proiectarea bazelor de date

Există multe tipuri de diagrame UML, care ajută proiectaŃii bazelor de date în munca
lor. Aceste diagrame pot fi folosite pentru adunarea cerinŃelor, pentru reprezentarea instalării,
etc. Cele mai importante diagrame UML sunt următoarele [32]:
Diagramă Descriere
Cazurile de utilizare arată comportamentul sistemului sau
Use Case a unei părŃi din sistem şi este o descriere a unui set de
secvenŃe de acŃiuni.
Diagrame de secvenŃe sau colaborare, care reprezintă
Interactions
interacŃiunea obiectelor în cadrul sistemului.
Diagrama de activităŃi este o schemă logică ce prezintă
fluxurile de control dintre activităŃi. Aceasta este folosită
Activity
la modelarea aspectelor dinamice ale sistemului şi
presupune modelarea unui proces pas cu pas.
Diagrama de stare prezintă în mod dinamic sistemul sau
Statechart
obiectele din sistem.
Class Este modelul logic pentru sistem.
Se modelează structura bazei de date incluzând şi
Database
constrângerile.
Diagrama de componente prezintă dependenŃele existente
între diverse componente soft ce compun un sistem
Component informatic. Aceste dependenŃe sunt statice sau dinamice.
Componenta are un model soft cu o interfaŃă bine
definită.
Diagramele de exploatare prezintă configuraŃia
Deployment elementelor de procesare din timpul execuŃiei şi
componentele, procesele şi obiectele care le conŃin.
253
5.10.8. Modelare business pentru proiectarea bazelor de date

ÎnŃelegerea funcŃionării unei firme şi a activităŃii acesteia nu este o problemă uşoară.
Este important să înŃelegem cu ce se ocupă firma, ce fel de informaŃii există, cine sunt
partenerii de afaceri, etc. Nu doar activitatea actuală este importantă ci şi perspectivele
viitoare ale firmei. Cele mai multe societăŃi, firme nu au un standard pentru reprezentarea
activităŃilor, mai ales instrumente de modelare a acestora.
Avem nevoie de următoarele informaŃii pentru crearea unui model corect [18]:
• Cum văd salariaŃii afacerea?
• Care este opinia lor în vederea înaintării firmei?
• Ce nu face bine firma?
• Ce realizează fiecare individ în parte?
5.10.8.1. Modelarea afacerii

Primul pas este adunarea informaŃiilor şi modelarea descrierilor. Trebuie să avem o
idee în ansamblu despre afacere, decât să citim doar cuvintele în sine.
Începem totdeauna cu diagramele Use case. O diagramă business use case reprezintă
funcŃiile cele mai importante ale unei afaceri. În modelarea afacerii este foarte important să
identifică şi să modelăm rolurile celor care intră în contact cu afacerea.
Modelul afacerii trebuie să conŃină vederi de interior şi vederi de exterior pentru a
sugera cele mai importante momente ale afacerii. Diagramele use case pot conŃine actori şi
use case-uri. Actor poate fi oricine şi orice care intră în contact cu sistemul. Important este de
reŃinut faptul că o persoană poate juca mai multe roluri şi un rol poate caracteriza mai multe
persoane. Actorul se mai poate defini ca un set de roluri pe care utilizatorul le foloseşte când
interacŃionează cazurile de utilizare. Poate fi un rol uman, un dispozitiv hard sau orice alt
sistem. Use case poate fi un şir de activităŃi care pot fi utili pentru actori. Ele implică
interacŃiunea dintre actori şi sistem.
Cele mai des folosite elemente use case [32]:
Nume simbol Simbol
Actor
Business Actor
Use Case
254
Business Use Case
Asociere
DependenŃă
Generalizare
În cadrul modelării business nu doar grupurile care lucrează sunt importante, ci şi

modul în care îşi desfăşoară activitatea aceştia. Modul de lucru este reprezentat de diagrama
de activităŃi. Acesta este o schemă logică ce prezintă fluxurile de control dintre activităŃi.
Aceasta este folosită la modelarea aspectelor dinamice ale sistemului şi presupune modelarea
unui proces pas cu pas. Cele mai des folosite elemente în cadrul unei diagrame de activităŃi
[4] [32]:
Nume simbol Simbol
Start
Sfârşit
Activitate
Punct de decizie
255
Nume
Culoare
Punct de sincronizare
Stare
TranziŃie
Flux de obiecte
Nume
Obiect
{State}
Diagramele de activităŃi se întorc până la use case-urile concrete. Diagramele de

activităŃi au mai multe scopuri [32]:
• ÎnŃelegerea afacerii curente
• ÎnŃelegere şi conceperea unor modificări
• Descoperirea redundanŃei în cadrul afacerii
• Descoperire întârzierilor în afaceri
• Descifrarea acelor activităŃi care influenŃează activitatea
5.10.8.2. Business-ul de astăzi

Prin înŃelegerea funcŃionării afacerii de astăzi putem să înŃelegem sistemele şi
funcŃionarea acestora. În acest pas ne ajută modelele de afaceri să identificăm acele activităŃi
care se repetă, care sunt redundante. Dacă privim asupra întregii afaceri trebuie să înŃelegem
ce procese, sisteme, software, hardware etc. există momentan. EsenŃa constă nu numai în
înŃelegerea afacerii actuale, ci şi în descoperirea perspectivelor viitoare.
5.10.9. Realizarea unui baze de date pentru un magazin virtual

În această parte ne ocupăm cu proiectarea bazei de date pentru un magazin virtual din
Târnăveni, judeŃul Mureş. Firma se ocupă cu achiziŃionarea şi vânzarea componentelor de
calculatoare.
O persoană poate consulta componentele existente, să le ordoneze pe categorii şi să le
comande on-line pe Internet. Pentru a comanda anumite produse trebuie să ne înregistrăm pe
256
site. Se introduce o adresă de mail şi o parolă, care va fi stocat în baze de date. O persoană
poate comanda mai multe produse.
Produsele vor fi trimise prin poştă sau prin Cargus (curier rapid) şi achitarea se face la
primirea produselor.
Administratorul poate introduce noi produse, respectiv poate modifica informaŃiile
produselor existente.
Scopul proiectului:
• reducerea erorilor umane
• mărirea eficienŃei
• acoperire naŃională (pe Internet)
Accentul se pune pe calitatea serviciilor şi nu pe managementul resurselor umane, pe
plata facturii sau alte procese.
5.10.9.1. Modelul business use case

Prima parte din modelare afacerii o reprezintă modelul business use. Acesta reflectă
punctul de vedere a celor din exterior şi contactul acestora cu serviciile oferite. Actorii din
exterior sunt actorii business. După negocierea cu firma, primul pas este identificarea actorilor
business.
Acesta este un model foarte simplu şi ne arată care actor business la care use case
aparŃine. Aceşti actori nu se referă la toŃi cei care intră în contact cu serviciile oferite. De
exemplu doamna Florica care se ocupă de curăŃenie în cadrul firmei, nu va fi luat în
considerare în acest model, deşi ea contribuie indirect la prestigiul firmei.
Pe parcursul discuŃiilor pot apărea noi actori care intră în contact cu firma, cum ar fi
transportatorii, firme de asigurări şi alte persoane interesate de firmă. Desigur putem avea mai
multe use case-uri, dar acestea trebuie să fie verificate, vor rămâne, dor acelea care sunt
importante din punct de vedere al firmei. Figura 5.68 prezintă un business use case posibil.
257
Figura 5.69 Model business use case

PerfecŃionarea modelului use case se poate face prin realizarea unui model pentru
fiecare proces de afacere. Diagramele de activităŃi conŃin procesul de afaceri şi prezintă
persoanele care aparŃin unor compartimente.
:Cumparator :Sistem de gest. a magazinului v irtual
Cerere Returnare
oferta inregistrari
Vizualizare Vizualizare
inregistarari pe categori
Comanda
Disponibil?
da
Realizare Modificare
comanda stoc
nu
Figura 5.70 Diagrama de activităŃi
258
În cadrul unei afaceri este extrem de important să privim lucrurile din punct de vedere
al actorilor business. Din acest motiv diagramele de activităŃi nu conŃin funcŃiile interioare ale
afacerii. Procesul business se sfârşeşte atunci când actorii business transferă gestiunea în
interiorul sistemului (Manager de înregistrări – business worker). Figura 5.69 conŃine o
diagramă de activitate.
5.10.9.2. Modelul de obiecte business

O altă parte din modelul afacerii o reprezintă modelul de obiecte business. Acesta
pune accentul pe modul în care participanŃii îşi execută sarcina în cadrul afacerii. Figura 5.71
conŃine un model simplu.
Produse inregistrate
Vizitator Facilitati
(from Use Case View)
Figura 5.71 Model de obiecte business

Diagramele secvenŃiale ne ajută să reprezentăm mult mai detaliat procesul business.
Aceste diagrame se citesc de vertical, de sus în jos.
EntităŃile prezente sunt în parte de sus a diagramei. Figura 5.72 prezintă o diagramă de
secvenŃă în care vizitatorul vizualizează anumite produse.
: Vizitator : Produse inregistrate

: Facilitati
1: Interesare
2: get
3: verificare cerere
4: Raspuns
5: Returnare inregistrare
Figura 5.72 Diagramă de secvenŃă
5.10.9.3. Modelul conceptual al datelor

Acest model ne ajută să înŃelegem mai bine care vor datele şi care mai târziu vor fi
incluse în tabele. Figura 5.73 conŃine o parte din acest model.
259
0..* 1 1 0..*
Proprietati Produse inregistrate Plan comanda
Figura 5.73 Modelul conceptual al datelor
Aceste modele ne-au ajutat să înŃelegem mai bine procesul afacerii şi putem începe să
analizăm şi proiectăm baza de date.
5.10.9.4. Proiectarea bazei de date utilizând UML

În această parte trecem de la model la proiectarea bazei de date. Instrumentul CASE
folosit este Rational Rose. În prima fază construim clasele necesare. Figura 5.74 conŃine
clasele necesare.
Categorii
Transportator
0..*
1
Produse 0..*
0..*
0..* 1
0..*
Descriere (proprietati)
0..*
1
Client Comanda
0..*
Figura 5.74 Diagrama de clase pentru magazinul virtual

Pasul următor este transformarea claselor în tabele după metoda bine cunoscută.
Figura 5.75 conŃine tabelele necesare.
1
Categorii
0..*
Transportator
1
1
1
0..* Produse
1 0..*
0..*
0..*
TranspProd
Descriere
(proprietati)
ProdComanda
0..*
1 1
0..*
Client
Comanda
Figura 5.75 Tabelele cele mai importante pentru magazinul virtual
260
Diagrama următoare conŃine tabelele cu toate atributele (figura 5.76).
Transportator Categorii
TransID : INTEGER CatID : INTEGER
Nume : VARCHAR(30) Nume : VARCHAR(30)
Localitate : VARCHAR(30)
<<PK>> PK_Categorii1()
<<PK>> PK_Transportator0()
1
1
0..*
0..*
Produse
TranspProd ProdID : INTEGER
F ProdID : INTEGER FK CatID : INTEGER
F TransID : INTEGER 1 Nume : VARCHAR(30)
Pret : REAL Bucati : INTEGER
0..* Pret : REAL
<<PK>> PK_TranspProd4() Poza : PICTURE
<<FK>> FK_Produse2()
<<FK>> FK_Transportator0() <<PK>> PK_Produse2()
1
<<FK>> FK_Categorii1()
0..*
1
ProdComanda 0..*
F ProdID : INTEGER
F ComID : INTEGER
Buc : INTEGER
Descriere (proprietati)
<<PK>> PK_ProdComanda6() DesID : INTEGER
<<FK>> FK_Produse2() FK ProdID : INTEGER
<<FK>> FK_Comnada7() Nume : VARCHAR(25)
UM : VARCHAR(3)
0..* Cantitate : INTEGER
<<PK>> PK_Descriere (proprietati)5()

<<FK>> FK_Produse2()
1
Client
Comanda ClientID : INTEGER
ComID : INTEGER Nume : VARCHAR(30)
FK
0..* 1
ClientID : INTEGER Telefon : VARCHAR(10)
Data : DATE Adresa : VARCHAR(50)
Cumparat : BIT(1) Parola : VARCHAR(15)
Email : VARCHAR(20)
<<PK>> PK_Comanda7() Iban : VARCHAR(13)
<<FK>> FK_Client8()
<<PK>> PK_Client8()
Figura 5.76 Tabelele cu atribute pentru magazinul virtual
Baza de date va putea fi implementat în MS SQL Server, Oracle, etc.
261
5.11. Arhitectura sistemelor informatice

Modelarea arhitecturii unui sistem informatic priveşte trei elemente distincte:
• Tehnologia de dezvoltare – instrumentele necesare pentru construirea
aplicaŃiilor (sisteme de gestiune a bazelor de date, limbaje şi medii de
programare, controlul codului sursă, gestiune configuraŃii, instalare, etc.). De
obicei acestea sunt cunoscute (stabilite) de la începutul proiectului. În această
fază se realizează o validare a corectitudinii şi eventual se fac anumite
modificări (dacă este posibil – resurse umane şi de timp);
• Tehnologia de acces la date – modul de accesare a datelor de către aplicaŃie
(inclusiv tehnologia de replicare şi infrastructura de acces la date);
• Tehnologia de proiectare a aplicaŃiei – modul de segmentare a aplicaŃiei,
strategii de împărŃire pe nivele, gestionarea nivelelor.
Pe măsură ce se cunosc cerinŃele aceste trei arhitecturi se rafinează şi se stabileşte
configuraŃia potrivită, rezultatul purtând numele de arhitectura de execuŃie.
Una dintre cele mai importante operaŃii care se realizează în etapa de proiectare a
arhitecturii unui sistem informatic este aceea de separare a serviciilor furnizate de acesta.
Până la apariŃia (utilizare pe scară largă) a tehnologiilor client-server şi a Internetului,
aplicaŃiile în general nu erau proiectate în spiritul separării serviciilor ce le ofereau.
O aplicaŃie o putem privi ca fiind structurată pe 3 nivele: nivelul de prezentare, de
logică a aplicaŃiei (de business) şi de date (a nu se face confuzie cu tipurile de clase: entitate,
control, interfaŃă). Aceste nivele induc şi două tipuri de independenŃă logică: modificarea unui
nivel nu trebuie să afecteze modificări ale altor nivele.
Nivelul (servicii) de prezentare: în general este vorba de o prezentare grafică sau ia
forma unor rapoarte. Separarea serviciilor de prezentare de cele de logică a aplicaŃiei permite
modificarea interfeŃei cu utilizatorul cu eforturi reduse (ex. implementarea unei interfeŃe web
pentru o aplicaŃie existentă). Implementare: prezentarea datelor, acceptarea datelor, interfaŃa
grafică cu utilizatorul. Obiective: uşurinŃă în utilizare, interacŃiune naturală şi intuitivă cu
utilizatorul, timpi rapizi de răspuns.
Nivelul de logică a aplicaŃiei: reprezintă cel mai dinamic nivel al unui sistem
informatic, deoarece regulile de logică a aplicaŃiei şi funcŃionalitatea se modifică mult mai
des. ‘Izolarea’ de celelalte nivele face ca impactul implementării unor modificări să fie redus.
În măsura în care este posibil, nivelul de logică trebuie să nu conŃină elemente legate de
interfaŃa utilizator sau acces la baza de date. Implementare: reguli de logică a aplicaŃiei,
controlul fluxului în aplicaŃie, impunerea unor restricŃii pentru păstrarea consistenŃei datelor.
Obiective: impunerea rigidă a regulilor de logică, conservarea investiŃiei în cod sursă,
reducerea costurilor de întreŃinere.
Nivelul de date: este cel mai static nivel, deoarece structurile de date şi relaŃia dintre
acestea se modifică rar. Implementare: robusteŃe în stocarea/interogarea datelor, accesul la
Sistemul de Gestiune a Bazelor de Date, controlul concurenŃei.
Obiective: baza de date consistentă şi sigură, partajarea informaŃiilor, timpi rapizi de
răspuns.
Cele trei nivele menŃionate sunt nivele logice. AplicaŃiile care au o astfel de
segmentare poartă denumirea de aplicaŃii cu arhitectură pe 3 nivele (3-tier architecture).
În general, acestea se implementează în 2 nivele fizice: calculator client (nivelele de
prezentare şi logică) şi server de date (nivelul de date). Această soluŃie a fost utilizată iniŃial
pentru aplicaŃii client/server distribuite. Implementarea nivelelor logice individual, ca nivele
fizice separate (client – nivel de prezentare, server de aplicaŃie – nivel de logică, server de
date – nivel de date) este impusă de următoarele aspecte:
262
• distribuŃia softului către clienŃi atunci când părŃi ale aplicaŃiei se modifică şi
configurarea aplicaŃiei pentru diverşi noi clienŃi (se referă la componentele de
acces la baza de date şi dificultatea instalării şi configurării dispozitivelor
ODBS pe maşini multiple)
• în funcŃie de tehnologia bazelor de date, costurile se ridică substanŃial dacă
fiecare staŃie de lucru necesită licenŃă de acces la baza de date
• scăderea performanŃei atunci când anumite calcule complexe sunt realizate pe
calculatoare client care au resurse reduse
Practic însă, arhitectura fizică a unei aplicaŃie poate fi împărŃită pe mai multe nivele
(N-tier architecture) => mai multe server de date şi servere de aplicaŃie.
Există mai multe strategii de proiectare optimă şi flexibilă a unei aplicaŃii. Minimum
necesar pentru o aplicaŃie care se doreşte să nu cunoască probleme majore la modifică pe o
perioadă de 1-2 ani este implementarea celor trei nivele menŃionate. Această abordare
reprezintă minimul necesar, deoarece există abordări care rafinează fiecare nivel în parte,
distingând mai multe subnivele.
Nivelul de logică a aplicaŃiei conŃine două subnivele:
• nivelul contextului aplicaŃiei – interacŃionează cu interfaŃa utilizator permit
filtrarea şi consistenŃa informaŃiilor pe măsură ce ele sunt introduse în sistem
(ex. o valoare a unui câmp limitează valorile ce pot fi introduse într-un alt
câmp)
• nivelul regulilor de logică – sunt legate de reguli de logică convenŃionale
(tradiŃionale) (ex. nr. de credite inferior unui anumit număr nu permite
promovarea unui student în anul următor
Nivelul de date conŃine trei sub-nivele:
• translatarea datelor – traducerea unei cereri logice (ca: adăugare, ştergere,
modificare) într-un limbaj care este compatibil cu modalitatea de stocare a
datelor (SQL)
• accesul la date – executarea cererii folosind funcŃii API (interfaŃă nativă a
bazei de date, ADO cu OLE/DB sau driver ODBC)
• baza de date – se referă la tehnologia bazei de date (SQL Server, Oracle,
Access)
Nivelele determinate mai sus se pot constitui în componente distincte ale sistemului
informatic. Determinarea mecanismului de comunicare între nivele se realizează răspunzând
la următoarele întrebări:
• Ce tehnologie de comunicare între-procese (IPC) va fi utilizată?
Mecanismul IPC poate fi gestionat de diverse tehnologii, ca RPC sau CORBA
(Common Object Request Broker Architecture), COM sau DCOM.
• Ce mecanism va fi utilizat pentru comunicarea între nivele atunci când un
IPC este utilizat?

1. Care sunt obiectivele abordării obiectuale?
2. Care sunt etapele de extragere a claselor?
3. Care sunt problemele ce apar la translatarea tabelelor relaŃionale în clase?
4. Care sunt aspectele importante ale OMT?
5. Prin ce este caracterizat un obiect?
6. Care sunt componentele obiectului?
7. Ce se înŃelege prin polimorfism?
263
8. Cu ce modele operează OMT?

9. Ce descrie modelul obiectual?
10. Ce descrie modelul dinamic?
11. Ce descrie modelul funcŃional?
12. Care sunt etapele abordării orientate obiect?
13. Prin ce se caracterizează o clasă în OMT, simbolul clasei?
14. Ce tipuri de asocieri avem în OMT?
15. Ce este generalizarea?
16. Ce este specializarea?
17. Ce este moştenirea?
18. Ce este evenimentul?
19. Ce este scenariu?
20. Ce este starea?
21. Ce sunt activităŃile?
22. Ce este

Limbă

Managementul Şi Proiectarea Sistemelor Informatice de Gestiune

Încărcat de

Informații document

Descriere:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Descriere:

Drepturi de autor:

Formate disponibile

Managementul Şi Proiectarea Sistemelor Informatice de Gestiune

Titlu original:

Încărcat de

Descriere:

Drepturi de autor:

Formate disponibile

CONSTANTIN AVORNICULUI MIHAI AVORNICULUI

PerfecŃionarea continuă a activităŃii economice, impune utilizarea pe scară tot mai

NoŃiuni de bază ale sistemelor.......................................................................... 13

1 NoŃiuni de bază ale sistemelor

1.1. Sisteme, sistemul informaŃional şi abordarea sistemică

1.1.1. Teoria sistemelor

O. Onicescu în 1979 arată că gradul de organizare a unui sistem poate fi măsurat cu

1.1.2. Feluri de sisteme

1.1.3. Abordarea cibernetică a sistemelor

Deci, orice sistem are o intrare x, o ieşire y, comparată cu o funcŃie obiectiv z.

1.1.4. Principiul de integrare

1.1.5. Feluri de integrări

interveni la toate nivelurile de organizare ale lumii materiale, precum şi la sistemele

1.1.6. Reglarea prin integrare

1.1.7. Sisteme integrate şi grade de integrare

1.1.8. Sisteme hiperintegrate

1.1.8.1. Cauzele hiperintegrării

1.2. Sistemul informaŃional: concept şi structură

1.2.1. Sistemul informaŃional

între elementele componente condiŃionează funcŃionarea întregului sistem, funcŃionare care

Analiza sistemică permite modelarea conducerii unui sistem, conducere ce nu poate fi

• al şaptelea nivel postulează faptul că sistemul coordonează deciziile de

APLICAłII INFORMATICE Sistemele de sprijinire a experŃilor

ARHITECTURA SITEMELOR INFORMAłIONALE Date

MEDIUL INTERN InformaŃii

MEDIUL EXTERN Furnizori

Figura 1.2 Componentele mediului de lucru a sistemelor [7] [21]

Problemele ridicate de proiectarea şi realizarea sistemelor, necesităŃile de coordonare

1.3. Sisteme informaŃionale economice, datele şi informaŃiile

1.3.1. EvoluŃia sistemelor informaŃionale

1.3.2. Felurile sistemelor informaŃionale

1.3.3. Ciclul prelucrării datelor

InformaŃia reprezintă datele transformate sub formă semnificativă pentru persoana

1.3.4. Componentele sistemelor economice

Unitatea reprezintă un element al sistemului economic ce nu se mai poate

• cu caracter de preŃ, ce arată valoarea numerică a variabilei mesajului cu

1.3.5. Sisteme economice integrate

Conducerea firmei AcŃionari

ProducŃie Aprovizionare Financiar

Figura 1.3 Exemplu de flux al informaŃiilor dintr-o unitate (firmă) [21]

1.4. Fluxul informaŃional

• fluxul de informaŃii prelevate din exterior şi utilizate de firmă

1.5. Circuitul informaŃional

1.6. FuncŃiile sistemului informaŃional

1.7. PerfecŃionarea sistemelor informaŃionale

1.8. Sistemul informatic

Flux informaŃional Subsistemul informaŃional

Figura 1.4 Locul sistemului informatic [21]

Sistemul informatic se interpune între sistemul decizional şi cel operaŃional, conform

Sistem de informare a conducerii operative

Sisteme de prelucrare a tranzacŃiilor

Comercial Personal ProducŃie Financiar Contabil

Figura 1.5 Imagine mai completă a sistemului informatic [44]

1.8.1. Sisteme informatice de gestiune (SIG)

1.8.2. Tipuri de sisteme informatice

1.8.2.1. Sisteme de prelucrare a tranzacŃiilor (SPT)

Comercial Contabi Produc.

1.8.2.2. Sisteme informatice de conducere (SIC)