Proiectarea Sistemelor Informatice de Gestiune

UNIVERSITATEA DANUBIUS GALAI DEPARTAMENTUL DE STUDII PENTRU NVMNT LA DISTAN
GABRIELA VRLAN Cristina Maria Enache Cristina Gabriela Zamfir
C S
Proiectarea sistemelor informatice de gestiune
I D
EDITURA FUNDAIEI ACADEMICE DANUBIUS GALAI 2008
Cuprins
Cuprins ......................................................................................................................................................... 2 Capitolul 1 Noiuni fundamentale........................................................................................................ 4
1.1. Noiunea de informaie ......................................................................................................................... . 4 1.2. Noiunea de sistem................................................................................................................................ . 5 1.3. Noiunea de sistem cibernetic............................................................................................................ . 6 1.4. Noiunea de sistem informaional ...................................................................................................... . 7 1.5. Noiunea de sistem informatic ........................................................................................................... . 9 2.1. Categorii de produse software ......................................................................................................... . 13 2.1.1. Procesoarele de text........................................................................................................................ . 14 2.1.2. Programe de calcul tabelar............................................................................................................. . 15 2.1.3. Software pentru baze de date ...................................................................................................... . 16 2.1.4. Programe de prezentare ................................................................................................................. . 17 2.1.5. Programe de lucru pe Internet...................................................................................................... . 18 2.2. Alte tipuri de produse software ...................................................................................................... . 19 2.2.1. Programe utilitare ............................................................................................................................ . 19 2.2.2. Pachete integrate ............................................................................................................................ .20 2.2.3. Proiectare asistat pe calculator ................................................................................................. .20 2.2.4. Programe de gestionare a documetelor i de birou .................................................................20 2.2.5. Shareware i public domain .......................................................................................................... . 21 2.3. Clasificarea sistemelor informatice.................................................................................................22
Capitolul 2 Sisteme informatice .........................................................................................................13
Curs 3 Stadiul actual i tendinele dezvoltrii sistemelor informatice ................................ 27
Capitolul 4 Metodologii de realizare a sistemelor informatice ................................................ 37
3.1. Evoluia sistemelor informaionale n cadrul firmelor..................................................................30 3.2. Sisteme integrate pentru firme ...................................................................................................... . 31 3.2.1. Enterprise Resource Planning ........................................................................................................ .32 3.2.2. Supply Chain Management.............................................................................................................. .33 3.2.3. Customer Relationship Management .............................................................................................34 3.2.4. Business Intelligence ...................................................................................................................... .35 3.3. Sistemul informatic de gestiune...................................................................................................... .36
Capitolul 5 Analiza i proiectarea orientat obiecte .............................................................. 50
4.1. Etape n proiectarea unui sistem informatic ..................................................................................38 4.2. Modele utilizate n proiectarea unui sistem informatic ..............................................................40 4.3. Metodologii de analiz i proiectare a sistemelor informatice ................................................ 41 4.3.1. Metodologii de analiz sistemic ................................................................................................... 41 4.3.2. Metodologii de analiz structurate ..............................................................................................45
5.1. Concepte utilizate n tehnologia orientat obiect .........................................................................50 5.2. Limbajul unificat de modelare - UML ..............................................................................................58 5.2.1. Evoluia limbajului UML ................................................................................................................. .59 5.2.2. Noiuni generale despre UML ...................................................................................................... .63 Cuprins - 2
Proiectarea sistemelor informatice de gestiune 5.2.3. Concepte UML................................................................................................................................... .66 5.2.4. Diagramele UML ............................................................................................................................... . 71
Cuprins - 3
Capitolul 6 Metode de proiectare a bazelor de date .................................................................. 84 BIBLIOGRAFIE ...................................................................................................................................... 87

6.1. Proiectarea bazelor de date utiliznd regulile de business ........................................................86
Cuprins - 4
Capitolul 1 Noiuni fundamentale

n informatic, la fel ca n orice tiin se opereaz cu noiuni, concepte, mrimi primare i derivate. Aceste concepte, noiuni sunt corelate prin legi pentru descrierea diferitelor fenomene i aplicaii care i sunt proprii. Determinarea i definirea acestor concepte i legi n mod riguros i clar, permite i uureaz abordarea, nelegerea i nsuirea informaticii ca tiin i ca meserie. Legea care se are n vedere nainte de toate, este legea potrivit creia calitatea informaiilor de ieire dintr-un sistem este n funcie de calitatea informaiilor la intrarea n sistem. Informatica a aprut ca tiin n al cincilea deceniu al secolului nostru, n strns legtur cu apariia i dezvoltarea calculatoarelor electronice. Din acest motiv informatica a fost un timp denumit tiina calculatoarelor".
1.1. Noiunea de informaie

Rezolvarea corespunztoare a problemelor din ce n ce mai complexe, n toate activitile vieii sociale i economice, reclam ridicarea calitii activitii de conducere la toate nivelele. Perfecionarea acestor activiti are ca premiz informaia. n sens primar, termenul de informaie nseamn o ntiinare, n general un mesaj despre anumite lucruri sau evenimente care au avut, au, sau vor avea loc". Prin informaie se nelege orice mesaj care mrete gradul de cunoatere al unei fiine umane n raport cu mediul nconjurtor (altfel spus, informaia reprezint cantitatea de noutate adus de un mesaj din lumea real nconjurtoare), fiind elementul cel mai dinamic al sistemelor informaionale, respectiv informatice, fiind elementul care d via acestor sisteme. n activitatea de conducere informaia este materia prim" cu care se lucreaz n vederea lurii deciziilor. Informaia reprezint obiectul prelucrrii i totodat, principala categorie de resurse utilizate n sistemele informaionale, respectiv informatice, alturi de celelalte categorii de resurse: personalul de specialitate, echipamentele de prelucrare i instrumentele de utilizare a acestor echipamente (metode i tehnici de analiz i proiectare, limbaje de programare, pachete standard de programe de aplicaii, sisteme de operare, metode i tehnici de organizare i prelucrare a informaiei etc.). Cu ct informaia este mai clar, mai concis cu att deciziile luate sunt mai corecte. Ea este cea care st la baza formulrii deciziilor, a aciunilor i a ndeplinirii obligaiilor. La baza informaiei st noiunea de dat. Prin dat se nelege orice mesaj primit de un receptor, sub o anumit form. Nu orice dat poate fi o informaie. Relaia dintre date i informaii este ilustrat n figura 1.1.
Fig.1.1. Relaia dintre informaii i date O definiie foarte concret asupra diferenei dintre informaie i dat a fost dat de Peter Ferdinand Drucker (1909-): Informaia este o dat plin de scop i de neles.
Noiuni fundamentale - 4
Toate datele care intr n sistem sunt analizate, triate i numai o parte dintre ele vor alctui informaiile necesare lurii unei decizii.
1.2. Noiunea de sistem

Conceptul de sistem apare n forma embrionar nc din filozofia antic greac. Afirmnd c ntregul este mai mult dect suma prilor, Aristotel d o prim definiie noiunii de sistem, care se va dezvolta i va evolua pentru a ajunge la forma actual de abia la nceputul secolului XX. Cel care pune bazele unei teorii nchegate privind teoria sistemele (este considerat fondatorul teoriei generale a sistemelor) este biologul german Ludwig von Bertalanffy (1901-1972) care ntre anii 1928 i 1950 public o serie de lucrri reprezentnd nceputurile teoriei generale a sistemelor i a sistemelor deschise. Astfel, el a dedus principiile universale care sunt valide pentru sisteme n general. n acest sens L. von Bertalanffy a reformulat mai nti conceptul clasic al sistemului i l-a determinat drept o categorie prin care se cunosc relaiile dintre obiecte i fenomene [Bertalanffy]. Conceptul nou dat sistemului reprezint un set de componente interdependente, o entitate complex n care spaiul-timp arat asemnrile structurale. n general prin sistem se nelege orice seciune a realitii n care se poate identifica un ansamblu de elemente materiale sau nemateriale (echipamente, metode, tehnici, fenomene, obiecte, procese, concepte, personal etc) interconectate printr-o mulime de relaii reciproce, precum i cu mediul nconjurtor i care acioneaz n comun n vederea realizrii unor obiective bine definite. n conformitate cu Open University (1980), un sistem este un ansamblu cu un scop (obiectiv), care are componente (pri) ce coexist n vederea deservirii unui interes uman particular, dar care se schimb la prsirea sistemului. Pe baza celor spuse mai nainte se poate spune ca prin sistem se nelege un ansamblu de elemente, structurat cu ajutorul relaiilor, ale crei pri se afl ntr-o puternic interdependen i independen fa de mediul nconjurtor, att elemente, ct i relaiile endogene (relaiile dintre elementele sistemului) sau exogene (relaiile dintre elementele sistemului i mediul nconjurtor) avnd un caracter dinamic, iar existena i funcionarea s fiind subordonat unui scop. Pentru realizarea funciilor unui sistem sunt necesare informaii. Fiecare sistem are ataat un anumit numr de informaii, care poart amprenta sistemului respectiv. Figura urmtoare ilustreaz corelaiile dintre un sistem, diferite subsisteme, precum i funciile acestuia.
Fig. 1.2. Relaiile dintre sistem i mediul nconjurtor Pentru a caracteriza noiunea de sistem este necesar s se pun n eviden urmtoarele cinci caracteristici (care reies din definiia sistemului): 1. mulimea de elemente;
2. 3. 4. 5.
relaiile (endogene) ntre elemente sistemului; relaiile cu mediul nconjurtor (exogene), intrrile i ieirile n/i din sistem; caracterul variabil n timp al elementelor i relaiilor; scopul, finalitatea sistemului.
Societatea comercial (firma) ca exemplu de sistem satisface n totalitate cele cinci laturi ale definiiei unui sistem: 1. mulimea de elemente este alctuit din: salariaii, elementele materiale, cldiri, materii prime, produse, mijloace financiare, informaionale etc.; 2. , 3. i 4. Relaiile ntre aceste elemente, ct i cu mediul nconjurtor, au un caracter dinamic, complex; 5. scopul este de a fabrica produse i a presta servicii, obinnd beneficii. Se poate rezuma c un sistem este un ansamblu de elemente; fiecare element al sistemului poate fi un subsistem, care la rndul lui poate fi considerat sistem format din elemente. Mulimea relaiilor ntre componentele unui sistem, precum i a relaiilor ntre componente i ansamblu formeaz structura sistemului. Modul n care elementele unui sistem sunt dispuse ntre ele reprezint structura static a sistemului. Dac legtura dintre aceste elemente este de compoziie, de apartenen, de utilizare, de vizibilitate a unui element asupra altuia, se spune c exist o relaie static ntre elemente; de asemenea exist i o interfa, care reprezint schimbul dinamic ntre dou elemente (un flux de informaii). Mulimea caracteristicilor unui sistem, la un moment dat, determin starea sistemului. Un sistem i adapteaz comportamentul la cerinele mediului su. De capacitatea de adaptare a sistemului i de viteza de reacie va depinde durata s de supravieuire. Reacia sistemului la un stimul trebuie s fie ct mai rapid i ct mai adecvat cu putin. [Vtui, 2000]. Sistemele sunt de mai multe tipuri, iar n funcie de criteriul de clasificare utilizat acestea sunt: dup natura lor: sisteme naturale (organismele vii); sisteme elaborate (tehnice, economice, conceptuale aici se regsesc sistemele informaionale); dup modul de funcionare: deschise (ieirile nu influeneaz intrrile); nchise (intrrile sunt influenate de ctre ieiri); dup comportament: deterministe (se cunosc intrrile, ieirile, i regulile care leag intrrile de ieiri); probabilistice (nondeterministe, incerte).
1.3. Noiunea de sistem cibernetic

Pentru analiza comportamentului sistemelor, n ansamblul lor, s-a propus conceptul de cutie neagr care reprezint sistemul privit ca un tot, fcnd abstracie de procesele sale interne. Cutia neagr primete impulsuri din partea mediului nconjurtor (intrrile n sistem) i dup ce preia aceste impulsuri, le transform n aciuni asupra mediului (ieirile din sistem). Acest sistem devine sistem cibernetic, atunci cnd apare fenomenul de reglare (numit conexiune invers sau feed-back), i care poate fi caracterizat ca n figura 1.3. Sintetiznd, se poate spune c noiunea de sistem cibernetic a aprut ca o necesitate de a privi un anumit sistem izolat din punct de vedere informaional. Aceasta presupune c n acest sistem cantitatea de informaie este finit, c orice intrare de informaie din mediu n sistem (intrare informaional) i orice ieire de informaie din sistem n mediu (ieire informaional) sunt controlabile sau observabile. Prin sistem cibernetic se nelege deci un sistem avnd cel puin o bucl de reglaj (feed-back) prin care se aplic de la ieirea sistemului un semnal la intrarea acestuia, unde un mecanism de comparaie
permite ca rezultatul compunerii semnalului de ieire cu cel de intrare s fie transmis blocului de decizie.
Fig. 1.3. Legtura feed-back ntr-un sistem cibernetic Sistemele cibernetice constituie o clas important de sisteme, iar dup cum se va vedea sistemele informaionale i informatice sunt sisteme cibernetice. Schema clasic a unui sistem cibernetic cu o bucl de reglaj este artat n figura urmtoare.
Fig. 1.4. Legtura feed-back ntr-un sistem cibernetic Un exemplu simplu ne poate arta diferena ntre un sistem i un sistem cibernetic: de pild, un autoturism este un sistem mecano-electric, dar nu este un sistem cibernetic, un autoturism mpreun cu conductorul auto constituie un sistem cibernetic.
1.4. Noiunea de sistem informaional

Un sistem poate fi controlat printr-un alt sistem, denumit sistem de conducere / comand sau de pilotaj. Acest sistem de conducere intr n legtur cu un sistem operant ce asigur, la rndul su, transformarea unor fluxuri de intrare n fluxuri de ieire. Sistemul de conducere are la baz anumite obiective determinate de specificul domeniului analizat, cadrul legislativ n materie i cerinele strategice ale domeniului. Rezult c sunt fixate obiective clare i directe pentru procesul de management, ce trebuie ndeplinite prin interaciunea dintre sistemul de conducere i cel operant. ntre sistemul de conducere i cel operant intervine un sistem informaional (un sistem de interfa ntre sistemul de conducere i cel operant), definit ca un set finit de concepte, metode, tehnici, procedee, modele, instrumente i procese utilizate pentru prelucrarea informaiilor i a interaciunilor provenite de la sistemul operant, n vederea transformrii lor n date ce pot fi furnizate sistemului de conducere, n condiii de eficien economic acceptabil, ntr-un context operaional controlabil, n limitele cadrului legal al domeniului supus analizei, n scopul realizrii funciilor organismului respectiv i a atributelor conducerii acestuia. Potrivit teoriei sistemelor orice organism conine aceste trei subsisteme: de conducere, informaional i operant. Fiecare dintre aceste subsisteme au un rol bine definit, i anume: sistemul operant (condus) este acela pe care se bazeaz activitatea organismului analizat, i care are rolul de a transforma fluxurile primare i / sau informaionale n fluxuri secundare sau de prelucrare; sistemul de conducere (de pilotaj) asigur declanarea activitii decizionale aplicat ntregului organism analizat. Acest subsistem permite monitorizarea, reglarea, coordonarea i controlul activitii respectivului organism n mediul su specific. El decide asupra organizrii, evoluiei i
interconexiunilor cu subsistemul operant i informaional. n acest context, sistemul de conducere este implicat fundamental n asigurarea eficienei activitii organismului; subsistemul informaional ndeplinete rolul de prelucrare manual / automat a informaiilor transmise de ctre sistemul operant, n raport cu cerinele cadrului legislativ i cu particularitile organizrii i funcionrii domeniului analizat, n scopul furnizrii datelor necesare controlului activitii globale asigurate de ctre sistemul de conducere. Practic, subsistemul informaional asigur, n general, stocarea, prelucrarea i difuzarea datelor necesare subsistemelor de interfa: de conducere i operant. Putem spune c subsistemul informaional are urmtoarele funcii: cunoaterea i specificul prelucrrilor realizate la nivelul subsistemului operant; furnizarea de date pertinente, exacte i operative subsistemului de conducere; implementarea funciilor eseniale relative la informaiile cu specific caracteristic domeniului analizat: generarea de informaii; memorarea acestor informaii; prelucrarea acestor informaii; comunicarea acestor informaii. Se observ c sistemul informaional se afl n relaie de subordonare fa de sistemul de conducere al sistemului. Relaia de subordonare este dat de faptul c sistemul informaional trebuie s produc acele informaii care sunt utile procesului de conducere al sistemului. Aceasta se concretizeaz prin cerinele i deciziile emise de acesta fa de sistemul informaional. Tot prin sistem informaional mai nelegem i partea dintr-un sistem care rspunde sensului restrns al analizei, adic sistemul privit exclusiv din punct de vedere al culegerii, transmiterii, prelucrrii i stocrii informaiilor. O definiie complet a noiunii de sistem informaional a fost dat de Buckingham (1987): Sistem informaional este un sistem care asambleaz, memoreaz, prelucreaz i obine informaii relevante pentru o organizaie (sau pentru o societate) astfel nct informaiile s fie accesibile i utile celor care doresc s le utilizeze i anume: manageri, staf, clieni i ceteni. Sistemul informaional este un sistem care presupune activitate uman (social) care poate implica sau nu prelucrarea pe calculator.
Sistemul informaional reprezint ansamblul informaiilor, surselor i nivelurilor consumatoare,
canalelor de circulaie, procedurilor i mijloacelor de tratare a informaiilor din cadrul sistemului cruia i este ataat. Sistemul informaional se mai poate defini drept ansamblul de resurse, circuite i procese informaionale. Orice activitate specific, sau organism specific, are un sistem informaional specific. n societatea uman orice activitate este definit de acte normative, care implicit determin i delimiteaz i sistemul informaional aferent acestei activiti. Orice sistem informaional trebuie s asigure organismului cruia i aparine informaii complete, n cantiti suficiente, corecte i la nivelul de operativitate cerut de nivelele consumatoare. Orice firm are propriul su sistem informaional, care ajut conducerea firmei, prin informaiile care le furnizeaz, s ia deciziile optime pentru conducerea acesteia. Sistemul informaional are un scop propriu i anume acela de a deservi activitatea de conducere cu informaii de fundamentare a deciziilor i are i metode proprii de realizare a scopului. n cadrul sistemului informaional economic se disting dou subsisteme care se afl n relaii de interdependen asigurnd n acelai timp i existena ntregului sistem ntr-o stare de echilibru (figura 1.5.). Cele dou subsisteme sunt: sistemul conductor al procesului informaional; procesul informaional al sistemului economic.
Fig. 1.5. Relaiile dintre cele dou subsisteme ale sistemului informaional n cadrul procesului informaional au loc o serie de transformri prin intermediul crora datele despre sistemul condus (real) i informaiile primite din afar sunt transformate n informaii utile procesului de conducere a sistemului economic. Procesul informaional poate fi separat pe mai multe etape i anume: 1. etapa de culegere a informaiilor, care face legtura direct cu sistemul real din care rezult datele; 2. o etap de prelucrare a informaiilor n care datele intr n componena diferitelor modele, sufer o serie de procese de grupare, selectare, astfel nct se obin informaii necesare procesului de conducere. n interiorul i ntre aceste etape, informaia circul prin aa numitul proces de transmitere a informaiei.
Sistemul conductor al procesului informaional primete de la procesul informaional informaii
referitoare la comportamentul acestuia; de asemenea mai primete de la sistemul conductor al organismului economic, cerine i decizii privitoare la nevoile de informare ale acestuia. Pe baza acestor cerine sistemul conductor al procesului informaional ntocmete programe prin intermediul crora procesul informaional s poat furniza sistemului conductor al organismului economic informaiile cerute. De asemenea, se pot ntocmi programe privitoare la nlturarea unor informaii considerate inutile, mbuntirea calitii informaiei conform constatrilor n procesul utilizrii lor, modificarea termenelor de livrare etc. Sistemul informaional se afl n relaie de subordonare fa de sistemul de conducere al sistemului economic. Relaia de subordonare este dat de faptul c sistemul informaional trebuie s produc acele informaii care sunt utile (cerute) procesului de conducere al sistemului economic. Aceasta se concretizeaz prin cerinele i deciziilor emise de acesta fa de sistemul informaional.
1.5. Noiunea de sistem informatic

Elementul revoluionar al mutaiilor care au determinat saltul calitativ al sistemelor informaionale este axat pe dezvoltarea i perfecionarea mijloacelor tehnice i a procedurilor de prelucrare a informaiilor n scopul automatizrii prelucrrii datelor. Automatizarea prelucrrii datelor cu ajutorul calculatorului electronic prezint saltul calitativ major de automatizare a unor pri ale sistemului informaional. Apariia calculatoarelor electronice i constituirea informaticii ca tiin, reprezint al treilea moment important n istoria informaional a omenirii, dup limbaj i tipar. Calculatorul electronic a produs o revoluie n societatea uman n ansamblul ei, cu implicaii deosebite n sfera informaional (prin modificarea activitii intelectuale a omului), cu preponderen n activitatea de conducere (management).
Dezvoltarea echipamentelor de calcul i ndeosebi a calculatoarelor a contribuit la perfecionarea modelelor economice, ceea ce a fcut posibil apariia sistemelor informatice i de conducere. Astfel, informatica se integreaz organic n activitatea economic i social, iar domeniile de utilizare a acestora se diversific n ritm rapid, prin includerea unor noi activiti umane. innd cont de cele spuse mai nainte se poate afirma c partea automatizat cu ajutorul calculatorului, din cadrul sistemului informaional al unui sistem se numete sistem informatic (prima dat aceste sisteme erau cunoscute sub denumirea de sisteme de prelucrare automat a datelor, SPAD). O definiie prim definiie a unui sistem informatic prin sistem informatic se nelege ansamblul de componente hardware/software, proceduri i oameni reunite i organizate pentru a prelucra date, n vederea ndeplinirii anumitor sarcini i realizrii unor performane msurabile prin criterii stabilite. O definiie complet: sistemul informatic este format dintr-un set finit de metode, tehnici, procedee, modele, strategii, instrumente, sisteme de tehnic de calcul, sisteme de comunicaie de date, personal specializat n informatic, sisteme organizatorice, restricii i faciliti legislative n materie, utilizate pentru generarea, transmiterea, prelucrarea algoritmic, difuzarea i interpretarea rezultatelor n vederea ndeplinirii funciilor organismului i a atributelor sistemului de gestiune (monitorizarea, reglarea, coordonarea, controlul). Toate aceste elemente au rolul de a asigura o funcionare optim i o reglare de tip conexiune invers (feed-back) a ntregului sistem aferent unui organism , n condiii de eficien economic i rentabilitate financiar acceptabile. Sistemul informatic poate avea caracter informaional-decizional sau numai strict informaional, dup cum este sau nu orientat spre rezolvarea, alturi de problemele pur informaionale, i a celor decizionale. Din definiia sistemului informatic rezult c ntre acesta i sistemul informaional, cruia i este subordonat, exist anumite raporturi, care n principal se refer la: 1. existena unui raport de compoziie, sau apartenen prin care sistemul informatic este o parte a sistemului informaional; 2. orice sistem informatic exist numai n cadrul unui sistem informaional care-l cuprinde i-l subordoneaz funcional, utilizndu-l ca infrastructura s tehnic; 3. sistemul informatic poart amprenta organismului pe care l reprezint.
Fig.1.6. Sructura unui sistem informatic Sistemul informatic se poate prezenta sub forma unei cutii negre, caracterizat de intrri, ieiri, reguli, proceduri, mijloace i metode. Sistemul informatic primete datele de la sistemul operant i, prin intermediul unei baze de proceduri asociate, asigur prelucrarea multipl a acestora, n conformitate cu un sistem procedural bazat pe algoritmi de prelucrare i de calcul, n vederea obinerii unor date de ieire sub form de rapoarte, indicatori sintetici, grafice, alte ieiri sub form mixt i / sau ieiri ctre alte sisteme informatice.
Noiuni fundamentale 1010
n mod practic, sistemul informatic folosete colecii de date organizate sub form de: baze de date gestionate prin sisteme de gestiune a bazelor de date (SGBD); baze de tabele gestionate prin sisteme de tip LOTUS sau derivate din acestea (EXCEL, QUATTRO).
Intrrile sunt asigurate prin operaiunile externe generate de activitatea desfurat la nivelul
sistemului (subsistemului) operant, operaii ce genereaz un flux de date care vor determina operaii de actualizare asupra bazelor de date. Deci, intrarea unui sistem informatic este informaia care se nregistreaz, sub forma datelor de intrare, n sistemul informatic respectiv, cu scopul de a fi prelucrat. Intrrile unui sistem informatic reprezint totalitatea datelor introduse n sistem cu scopul de a fi prelucrate, n conformitate cu regulile funcionale i / sau organizatorice specifice sistemului economic care-l utilizeaz i cu legislaia n vigoare. Intrrile unui sistem informatic pot fi obinute prin: Introducerea datelor din documente (tastatur, scanare). Transfer electronic de date (reea local, reea de arie ntins).
Prelucrrile unui sistem informatic reprezint totalitatea operaiilor efectuate asupra datelor
nregistrate n i respectiv pentru obinerea informaiilor necesare funcionrii unui sistem economic.
Ieirile unui sistem informatic reprezint totalitatea rezultatelor prelucrrilor efectuate asupra
datelor nregistrate n i respectiv, prin interpretarea crora se pot obine informaiile care fundamenteaz deciziile manageriale pe toate nivelele organizatorice ale sistemului economic care l utilizeaz. Ele reprezint: Datele de pe documentele ntocmite de sistem. Datele exportate ctre alte sisteme informatice. Reiese faptul c ieirile sunt obinute ca urmare a prelucrrii datelor de intrare, fiind concretizate n urmtoarele tipuri de rapoarte: rapoarte liste situaii: conin indicatori sintetici i / sau analitici sub form tabelar, obinui prin diferite procese de prelucrare aplicate asupra coleciilor de date, fiind necesare luri de decizii cu caracter tactic, strategic i operativ; indicatori sintetici: conin elemente sintetice / analitice cu un grad maxim de prelucrare i reprezentative, afiabile pe ecran, i sunt folosite pentru informarea i luarea operativ a deciziilor de ctre manageri sau personalul de specialitate; grafice: arat tendina unor fenomene sau procese pe o perioad de timp sau ponderea unor elemente ntr-un asemenea fenomen; mixte: se prezint sun forma unor documente elaborate pentru factorii de decizie i conin text explicativ, repoarte, indicatori sintetici i grafice, inclusiv combinaii ale acestor tipuri de ieiri; ieiri ctre alte sisteme informatice: sunt utilizate pentru transmiterea on-line de date ntre diverse organisme, fiind necesare informrii reciproce sau raportrii cu privire la fenomene i procesele actuale, trecute i / sau viitoare. Principalele obiective ale unui sistem informatic sunt: 1. cunoaterea strii sistemului; 2. cuantificarea rezultatelor sistemului; 3. creterea operativitii n activitatea managerial a sistemului; 4. utilizarea eficient a resurselor sistemului. Fiecare organism (societate, ntreprindere, firm) are de ndeplinit mai multe atribuii pentru a-i atinge scopul pentru care a fost creat (pentru care, de fapt, funcioneaz). Pentru ca un sistem informatic s fie integrat unui organism el trebuie s fie ataat n mod intim tuturor funciunilor
automatizabile din cadrul acestuia. Deci fiecrei funciuni a organismului, i va corespunde un subsistem informatic, care toate mpreun vor alctui sistemul informatic al acestuia. nc de la nceputul utilizrii tehnicii de calcul n prelucrarea datelor la nivelul unei organizaii sa impus necesitatea ca sistemul informatic s fie mprit n mai multe subsisteme. Partea sistemului informatic asociat unei funciuni se numete subsistem i este caracterizat de un ansamblu de operaiuni similare care realizeaz obiectivele sistemului pentru partea automatizat din funciunea respectiv. mprirea pe subsisteme a fost determinat de o serie de factori precum: 1. tipul de producie i ramura din care face parte ntreprinderea; 2. gradul de complexitate al sistemului informatic; 3. experiena i numrul membrilor echipei de proiectare; 4. condiiile existente n ntreprindere i caracteristicile sistemului informaional existent; 5. gradul de utilizare al echipamentelor; 6. situaia codificrii i calitatea documentaiei; 7. gradul de pregtire al documentaiei de proiectare i tehnologice etc. Astfel s-au constituit subsisteme pe: 1. funciunile ntreprinderii (producie, comercial, financiar-contabil, personal etc.); 2. pe grupuri de activiti de conducere (planificare i urmrire, gestiunea stocurilor, programarea, lansarea i urmrirea fabricaiei, gestiunea livrrilor etc.); 3. subsistemul care conine modelele pentru pregtirea deciziilor; 4. subsistemul care asigur gestiunea bazei de date etc. Modul de constituire al subsistemelor a fost n general influenat de gndirea realizrii de aplicaii, care a premers gndirii sistemice; care consider c mprirea pe subsisteme trebuie subordonat n principal necesitilor implementrii sistemului informatic, sau mai corect al diferitelor pri ale sistemului informatic i, deasemenea, trebuie avut n vedere n mod consecvent caracterul cibernetic al oricrui subsistem al sistemului informatic (structurat ca sistem cibernetic). Deoarece n cadrul oricrui ansamblu de operaiuni se pot regrupa subansambluri de operaiuni de acelai tip, tot aa n cadrul unui subsistem se pot decupa subsisteme, denumite i aplicaii, tratate pe calculator ca lucrri independente. Aplicaia, sau subsistemul, st n raport cu subsistemul cum st partea fa de ntreg. Cele mai importante subsisteme, din cadrul unui sistem al firmei, sunt: 1. subsistemul de resurse umane; 2. subsistemul de producie; 3. subsistemul financiar contabil; 4. subsistemul de marketing. n cazul societilor industriale sistemul informatic se structureaz de obicei n urmtoarele subsisteme: planificarea tehnico-economic; pregtirea fabricaiei; programarea, lansarea i urmrirea produciei; marketing; personal-salarizare; financiar contabil.
Capitolul 2 Sisteme informatice

Pornind de la definiia sistemului informatic, sistemul informatic este format dintr-un set finit de metode, tehnici, procedee, modele, strategii, instrumente, sisteme de tehnic de calcul, sisteme de comunicaie de date, personal specializat n informatic, sisteme organizatorice, restricii i faciliti legislative n materie, utilizate pentru generarea, transmiterea, prelucrarea algoritmic, difuzarea i interpretarea rezultatelor n vederea ndeplinirii funciilor organismului i a atributelor sistemului de gestiune (monitorizarea, reglarea, coordonarea, controlul), se poate defini arhitectura unui sistem informatic, care este alctuit din urmtoarele componente: sistemul de tehnic de calcul este acel sistem care permite realizarea anumitor activiti, avnd la baz prelucrarea informaiei, alctuit din dou subsisteme principale: hardware i software, este deci alctuit din calculatoarele, mpreun cu produsele software utilizate, care sunt puse la dispoziia utilizatorilor sistemului informatic; sistemul de comunicaie de date este reprezentat de ansamblul de mijloace tehnice interdependente care asigur transferul informaiilor ntre dou sisteme de calcul oarecare, aflate la o anumit distan unul fa de altul. Un sistem de comunicaie leag ntre ele dou sau mai multe calculatoare cu scopul de a asigura transferul de date ntre ele, prin intermediul unei reele de calculatoare. n funcie de tipul reelei de calculatoare (reea local, metropolitan, de arie ntins etc.) aceste sisteme de comunicaie sunt mai mult sau mai puin complexe. Datorit faptului c n ultimii ani Internet-ul a nceput s fie utilizat ca suport pentru afacerile firmelor dezvoltarea acestor sisteme de comunicaie capt o amploare din ce n ce mai mare. personalul specializat n informatic i utilizatorii, sau sistemul de resurse umane, este format din mulimea de persoane cu pregtire diferite care interacioneaz cu sistemul informatic n vederea ndeplinirii funciilor acestuia. n funcie de sarcinile i / sau funciile pe care le ocup fiecare persoan n raport cu sistemul informatic de dezvoltat, sau utilizat, raport care este stabilit n funcie de nivelul de pregtire a fiecrei persoane n parte, aceasta va face parte dintro anumit categorie de personal: personal de specialitate i personalul de exploatare. sistemul organizatoric reprezint totalitatea metodelor i tehnicilor organizatorice utilizate n vederea atingerii funciei sistemului informatic. Sistemele informatice depind n mod esenial de resursele software care ajut utilizatorii s lucreze cu echipamentul hardware i s acceseze reelele de calculatoare. Astfel software-ul asigur introducerea, prelucrare, ieirea, datelor precum i controlul sistemelor informatice.
2.1. Categorii de produse software

Software-ul se clasific n dou mari categorii de programe: A. Software-ul de aplica ii este reprezentat de programele care acioneaz direct asupra unui domeniu de utilizare particular pentru a asigura procesarea informaiilor necesare utilizatorilor finali. Acest tip de programe se regsete ntr-o multitudine de variante, versiuni, platforme de lucru, productori i pre. Software-ul de aplicaii are o zon determinat de utilizare (de exemplu, domeniul economic) iar n cadrul ei, zona poate fi i mai specific (de exemplu, calcul tabelar). n prezent se remarc folosirea cu precdere de pachete integrate (suite) pentru activitile de birou care au un rol important n creterea producivitii. Acestea cuprind: procesor de texte, calcul tabelar, baze de date, programe de prezentare i de lucru pe Internet. Cele mai importante aplicaii de acest tip sunt: MS Office, Corel Word Perfect Office, Lotus Smart Suite i Sun Star Office.
Clasificarea sistemelor informatice 1313
O clasificare a acestora pentru domeniul economic poate fi: 1. Programe de procesare de text. 2. Programe de calcul tabelar. 3. Programe de management al bazelor de date. 4. Programe de prezentri i grafic. 5. Programe de lucru n Internet i pot electronic. Avantajele acestor grupuri de aplicaii sunt: determin creterea productivitii, faciliteaz comunicaia n interiorul organizaiei, permit lucrul n reea i integreaz aplicaiile Internet; includ toate tipurile de programe necesare activitii de birou; costul achiziiei unui pachet integrat este mai mic dect al aplicaiilor cumprate individual; toate aplicaiile din pachet arat aproape identic ceea ce le face mai uor de nvat i de lucrat; au faciliti importante de transfer al informaiilor dintr-o aplicaie n alta. Dezavantaje: multe din facilitile oferite de aceste programe nu sunt folosite de utilizatori; au nevoie de resurse mari pentru a funciona corespunztor (spaiu pe disc, memorie); pot afecta viteza de lucru i puterea sistemului. Tot n aceast categorie productorii de software au dezvoltat o categorie de pachete integrate de nivel mediu care au preluat o serie din caracteristicile celor de mai sus. Acestea combin funciile mai multor tipuri de programe n unul singur. Cele mai cunoscute sunt: MS Works, Lotus Works, Claris Works. Ca avantaje ar putea fi resursele modeste pe care le utilizeaz i costul sub 100 US $, iar dezavantajul este c nu au performanele programelor individuale. B. Software-ul de sistem sunt programele care gestioneaz i manipuleaz resursele i activitile unui computer fiind o interfa ntre computer i software-ul de aplicaii. n aceast categorie se includ urmtoarele programe: 1. Sisteme de operare asigur interfaa dintre calculator i sofyware-ul de aplicaii. Exemple: MS DOS,Windows, Linux, Mac OS, OS2 etc. Sistemul de operare este un program principal, permanent stocat n memorie, lansat n execuie la pornirea calculatorului care ndeplinete funcii de coordonare i control asupra resurselor fizice ale calculatorului i care intermediaz dialogul om-calculator. Deci, el asigur i alte faciliti ca vizualizarea de fiiere, tergere, copieri de fiiere. Mai are rolul de a nmagazina i regsi datele pe disc, organizeaz intrrile de date de la tastatur, trimite datele ctre imprimant i verific dac tiprirea decurge normal, controleaz monitorul. Exist diverse sisteme de operare, diferite ntre ele n funcie de arhitectura calculatorului, codurile main, instruciuni etc. Scopul unui sistem de operare este de a face comenzile mainii transparente utilizatorului. Acelai sistem de operare poate fi implementat pe o varietate larg de maini, cu viteze i capaciti diferite. Cele mai multe softuri sunt fcute ca lucrul cu ele s fie intermediat de sistemul de operare. Datorit faptului c sistemul de operare este acelai, programele pot rula pe diverse tipuri de computer fr sau cu mici modificri. Acest element de portabilitate a ajutat ca softul s se diversifice. 2. Programe de reea care asigur comunicaia dintre calculatoare. De exemplu: Windows NT, 2000 sau Novell. 3. Programe utilitare ce efectueaz diverse activiti precum: diagnoza utilizrii sistemului i resurselor, protecia antivirus, arhivarea documentelor, optimizarea sistemului etc. 2.1.1. Procesoarele de text A da o definiie exact unui procesor de texte este o activitate hazardat, sortit eecului, datorit complexitii i diferenelor specifice ntre att de diversele pachete numite procesoare de texte. Cert este c un procesor de texte este un pachet de programe ce lucreaz asupra unui text n vederea
imprimrii acestuia, chiar dac textul va fi transmis prin fax sau pot electronic, va fi stocat n fiiere text, ce vor reprezenta surse ale unui program sau documentaii on-line etc. Evolund de la minieditoare de texte, cu performane sczute, ca Edit pentru sistemul de operare MSDOS, Write pentru sistemul de operare Windows i ajungnd pn la procesoare profesionale ca Word for Windows, AmiPro, JustWrite, procesoarele de texte realizeaz acum toate operaiile necesare pentru editare, machetare, formatare, vizualizare, tiprire, verificare i multe alte operaii ce dau unui text un aspect foarte plcut i atractiv. Rspndirea interfeelor grafice, de tipul WYSIWYG (What You See Is What You Get ceea ce vezi (pe ecran) este ceea ce vei avea (la imprimant)), au dus la apropierea din ce n ce mai mare a tipografului, tehnoredactorului, secretarei i nu n ultimul rnd, al oricrui om ce vrea s scrie un text, de calculator prin procesorul de texte i ndeprtarea s de maina de scris clasic. Integrarea aplicaiilor. Procesoarele de texte nu lucreaz n general singure, ci coopereaz cu alte aplicaii ce realizeaz operaii complexe. Orice program care se respect tie s se descurce cu cteva formate grafice, spreadsheet-uri, cu formatele celor mai populare baze de date i mai ales cu diverse formate de text. Pe lng procesorul de texte se gsesc de obicei, un editor de ecuaii, un editor de grafic, un editor de stil i art i multe altele. Mediul Windows, prin multitasking (reprezint o modalitate de lucru oferit de un sistem de operare, prin care un calculator poate executa mai multe task-uri n acelai timp; un task este o aplicaie sau program care este executat la un moment dat), ofer procesoarelor de texte posibilitatea de a folosi n comun alte aplicaii ale sistemului. Astfel, exist posibilitatea de a ataa documente mesajelor trimise prin fax sau pot electronic. De asemenea se pot crea legturi dinamice (DDE Dynamic Data Exchange, realizeaz un transfer al datelor dintr-o aplicaie Windows n alta, sau OLE Object Linking and Embedding, permite inserarea unui obiect creat printr-un anumit program n interiorul altui obiect creat printr-un program diferit; legtura ntre cele dou obiecte fiind gestionat de sistemul de operare) cu datele unei aplicaii Windows, astfel nct orice actualizare a datelor originale se reflect n document, dac aplicaiile sunt deschise simultan (DDE) sau la cerere (OLE). Se poate sintetiza c programele de procesat text permit crearea, modificarea i tiprirea de documente aflate n form digital. Avantaje utilizrii lor: capacitatea de a edita brouri, manuale etc.; utilizarea i convertirea de documente din/n formatul HTML pentru Internet; corectarea textului, gramaticii i traducere. Programele DTP (DeskT Publishing) sunt programe mai specializate n producerea de cri, manuale, brouri i care ofer mai multe faciliti n acest domeniu (grile, formatri, stiluri). 2.1.2. Programe de calcul tabelar Sunt programe utilizate pentru analize de business, planificare i modelare. Acestea ofer un mod electronic de nlocuire a tabelelor de hrtie, creionului i a calculatorului de buzunar. Programele se prezint sub forma unui tabel cu un numr foarte mare de rnduri i coloane, permit combinarea acestora, calcule, grafice, analize etc. Totodat permit accesarea i interogarea bazelor de date de pe Internet pentru al le prelucra. Trebuie amintit faptul c locul unde s-au cerut pentru prima dat calculatoare PC foarte puternice a fost Wall Street. Domeniul economic este, se pare, unul primordial pentru producia de hardware i software. Dac din punct de vedere al hardware-ului problemele erau n cea mai mare parte rezolvate, din pcate software-ul era mai puin dezvoltat i devenise apanajul unor specialiti. Aceasta a determinat necesitatea unor programe care s fie foarte uor accesibile i novicilor, nemaifcnd necesar intermedierea prin specialiti (analiti progrmatori).
Cum ntr-o economie de pia apariia unei nevoi duce la apariia mijlocului prin care este satisfcut, pe fondul dezvoltrii hardware-ului, la nceputul anilor 1980 au aprut primele programe de calcul tabelar numite i spreadsheets. Programele de calcul tabelar sunt pachete de programe (dac sun prea pretenios ele se numesc mai simplu programe) care permit manipularea datelor aranjate sub form de tabel. Mai simplu spus pentru cei ce au tangen cu activitatea de birou, acetia trebuie s se gndeasc la un document cumulativ dar foarte foarte mare. Avantajele utilizrii acestor programe const n faptul c odat stabilite formulele, relaiile ntre celule i introduse datele, imediat rezultatele calculelor vor fi afiate i mai mult, la modificarea datelor sau o alt introducere ulterioar, rezultatele calculelor vor fi refcute imediat sesizndu-se modificarea intervenit. Posibilitatea de a crea modele fiind foarte dezvoltat se pot dezvolta modele extrem de complexe, se pot elabora i diverse analize i calcule financiare (cnd ne-am referit la faptul c spreadsheet-urile acoper domeniul economic vom mai meniona c exist o multitudine de funcii financiare, contabile, statistice, matematice i chiar inginereti, care vin s uureze i mai mult lucrul cu aceste programe). Aceste analize se pot face uurin folosind comenzile what-if (ce s-ar ntmpla dac ...), solve for (rezolv pentru ...) sau optimizri. 2.1.3. Software pentru baze de date Fiecare organizaie lucreaz cu un numr mai mic sau mai mare de documente i date. Unele date se afl n arhive, altele n circulaie, unele sunt create n interior, altele n exterior. Indiferent de forma, coninutul sau proveniena lor, ele formeaz un volum de informaie care este vital pentru buna administrare i succesul activitii respectivei organizaii. Toate aceste colecii de date mpreun cu aplicaiile ce utilizeaz datele respective, formeaz o baz de date, mai exact o baz de date i un sistem de gestiune a bazelor de date (SGBD), care de fapt reprezint software-ul utilizat pentru dezvoltarea aplicaiilor cu baze de date. Deci bazele de date cuprind colecii structurate de date, sistemul de gestiune a acestora cu interogri, machete, rapoarte, aplicaii precum i mediile de interfaare i dezvoltare a aplicaiilor referitoare la coleciile de date. Gestiunea datelor n cadrul unor organizaii mari sau a celor cu un flux rapid de date devine o problem care consum timpul, energia i nervii unui numr considerabil de funcionari. Consum deci resurse, bani. Cci indiferent dac este vorba de facturi sau de datele secrete ale unui nou produs, exist situaii n care afaceri extraordinare sau simpla imagine public depind de eficiena cu care sunt manipulate aceste date. Calculatoarele ncearc s fac ordine n milioanele de date de diverse tipuri ce tind s sufoce organizaiile. Dar n spatele lor trebuie mereu s se afle cineva care s le conduc i s neleag tot fluxul acestora. Folosirea sistemelor de gestiune a bazelor de date n mod eficient nseamn economie de timp, de munc, de bani i nu n ultimul rnd confer competitivitate i stil. Trsturi standard n orice sistem de gestiune a bazelor de date primul lucru care trebuie fcut este stabilirea structurii (organizrii) datelor. Structura relaional a reuit s se impun n domeniul SGBD-urilor, astfel nct marea majoritate a acestora sunt relaionale, de aceea se vor trata numai acest tip de SGBD. O baz de date reprezint o colecie de date organizate sub form de tabele (n terminologia bazelor de date, un fiier se numete tabel), date ntre care exist anumite legturi (numite relaii logice), i care permite cutarea rapid i regsirea informaiilor utiliznd calculatorul. Tabelele sunt organizate pe linii i coloane. Coloanele se mai numesc cmpuri (fields) iar liniile se mai numesc nregistrri (records).
Utilizarea SBBD-urilor este dat de anumite faciliti, printre care se enumer: Una din facilitile care se va gsi la majoritatea SGBD-urilor, dar diferit realizat de la program la program, este scrierea aplicaiilor (programarea). Avnd la dispoziie limbaje de programare specifice bazelor de date, se pot dezvolta diverse proceduri ce personalizeaz cu adevrat aplicaia respectiv. Programele pot fi scrise instruciune cu instruciune sau descrise prin evenimente, pot exista structuri de gen WHILE, FOR, CASE sau nu. Se pot genera n unele SGBD-uri i fiierele sau codurile executabile .EXE, ce pot fi de sine stttoare (stand alone) sau minimale, adic folosesc biblioteci externe cu care se pot lega dinamic. O alt facilitate foarte important este securitatea datelor. Se pot proteja astfel, prin parole, nregistrri sau fiiere, grupuri de fiiere i aplicaii. Exist diverse nivele de protecie, stabilite n general, de administratorul bazei de date. n cazul lucrului n reea, securitatea datelor este foarte important. Sunt probleme create de accesul la date partajat sau accesul la date numai pentru vizualizare i nu pentru modificare sau restructurare. Poate fi protejat chiar i intrarea n SGBD, prin parole pe dou sau mai multe nivele. Orice aplicaie mai serioas trebuie prezentat ntr-o form ct mai accesibil. Acest lucru se realizeaz de obicei, prin ceea ce se numete interfaa aplicaiei sau meniurile. Meniurile sunt dialoguri la nivel utilizator prin care se pot selecta diverse ci de urmat n aplicaia respectiv. Exist n general un generator de meniuri ce scoate n final cod-program, care poate fi legat de restul prilor din aplicaie. Se pot folosi meniuri Pop-up, Pull-down, butoane radio, de bifare, de apsare etc., ce pot fi lansate printr-o combinaie de taste (shortcut) sau selectate cu mouse-ul i care dau aplicaiei o fa mult mai prietenoas i mai ales mai accesibil. Relaii ntre fiiere (join) sunt necesare n cazul n care nu se dorete sau nu se poate s se pstreze informaii complete despre un obiect. Descrierea obiectului, aflat n alt tabel, poate fi accesat prin stabilirea unei relaii cu aceast descriere, evitndu-se astfel multiplicarea aceleiai informaii i inconsistena informaiei. n bazele de date relaionale aceast trimitere se realizeaz printr-o adres, un cod. Pot fi stabilite relaii de tipul unu-la-unu (one to one) sau unu-la-muli (one to many). Ele pot fi terse sau modificate n mod interactiv sau descriptiv. O alt problem realizat n mod diferit de diversele SGBD-uri este cea a importului i exportului de fiiere sau date, adic a compatibilitii. n lumea bazelor de date sunt ncetenite cteva formate standard de tip xBase, ISAM (Indexed Sequential Access Method), ceea ce face ca SGBD-urile s poat lucra nu numai cu baze de date proprii ci i cu altele. Astfel se pot porta ntre ele baze de date dBASE cu FoxPro, Paradox, Access, Informix; ba chiar exist un SGBD numit Magic care nu are format propriu ci folosete drivere specifice pentru celelalte baze de date. n fine, o alt facilitate a SGBD-urilor este dat de existena Help-urilor interactive sau obinuite, ce pot scoate utilizatorul din multe ncurcturi. Bazele de date sub Windows ofer suport pentru DDE i OLE (grafic, imagine) ce permite elaborarea unor aplicaii cu imagine, sunet i animaie - multimedia. 2.1.4. Programe de prezentare Programele de prezentare sunt utilizate pentru a converti diverse informaii n elemente grafice. Aceste programe ofer capaciti multimedia (utilizarea de fotografii, animaii, sunete i secvene video) dar i posibiliti de a face prezentri pentru Internet. Avantaje: asigur o comunicare simpl i sugestiv; construiesc prezentri eficiente; ofer posibiliti de interactivitate. Programele de grafic s-au dezvoltat uimitor dup apariia unei interfee grafice i a unor plci grafice puternice, cu posibilitatea definirii unui numr mare de culori i forme. Folosesc, n general, mouse-ul, creioanele optice, uneltele care sunt la dispoziia utilizatorilor i sunt afiate sub forma unor butoane
pe ecran (creioane, foarfec, gum, pensule, rolluri, lupe etc.). Dispun de palete de culori prin care se poate selecta o culoare predefinit sau defini o culoare utilizator (custom). Genereaz formate grafice specifice, unele de tip bitmap (orientate pe puncte), altele de tip vectorial (orientate pe curbe, linii). Programele de grafic actuale sunt programe orientate pe obiecte grafice, dar mai rezist nc i programe de grafic orientate ecran. Exist n aceast lume a graficii, programe de grafic utilitar sau de afaceri (Bussines Graphics) care sunt extrem de pretenioase din punct de vedere hardware dar sunt suficiente de simple n utilizare. Ele sunt dotate cu seturi ample de desene prefabricate (Clip Art) i au n general formate vectoriale. Dintre acestea putem aminti: Powerpoint (Microsoft), Freelance Graphics (Lotus), Corel Presentations (Corel), Persuasion (Aldus), Charisma (Micrografx). O a doua categorie o constituie procesoarele de imagini ce sunt utilizate pentru pictur, afie, colaje, retuuri fotografice, animaie, prelucrare video. Prelucrrile oferite de astfel de programe merg de la reglaje de contraste i luminozitate, efecte speciale de vizualizare i transformare a imaginii, deformri plane i spaiale, efecte de posterizare, pn la colorarea imaginilor alb-negru, capturi ale ecranelor, adugare de perspective i multe altele. Din aceast categorie se poate semnala cteva, menionnd c toate sunt sub Windows sau sub Mac: PhotoShop (Adobe); PhotoStyler (Aldus); Picture Publisher, PhotoMagic (Micrografx); Corel Draw (Corel); Painter (Fractal Design); Image Wizard (Image Ware); Image Pals (ULead). Programele de prezentare sunt programe de grafic, sunet i animaie menite s realizeze mult mai ocant i diversificat prezentri necesare lansrii unui produs nou, reclame publicitare, clipuri, instruire asistat de calculator etc. Paleta lor este foarte larg, mergnd de la simple programe de grafic i ajungnd la programe multimedia, adic programe ce pot lucra cu imagini video, muzic, animaie. 2.1.5. Programe de lucru pe Internet ntre cele mai importante produse software utilizate n prezent, aflate ntr-o dezvoltare permanent se afl web browser ele. Netscape Navigator, Internet Explorer sau Opera sunt cele mai rspndite programe care lucreaz n Internet i ofer accesul la resursele acestuia. Domeniile de utilizare a lor sunt: navigare n Internet; cutare de informaii; pot electronic; transferul de fiiere; grupuri de discui; alte aplicaii (chat, video-chat, fax). Pota electronic (e-mail) a schimbat modul de lucru al oamenilor i posibilitile de comunicare. Acest sistem permite transmisia i recepia de mesaje n form electronic (digital) prin Internet sau alte reele. Facilitile potei electronice sunt: transmitere/primirea de mesaje de la/ctre unul sau mai muli utilizatori, folosirea de mailing list; confidenialitate i securitate; posibilitatea rspunsului automat; crearea de liste de subscripie; acces la cutia potal din mai multe locuri; transfer de fiiere (text sau multimedia);
filtrarea i sortarea mesajelor primite; utilizarea de ageni inteligeni.
2.2. Alte tipuri de produse software

Evident software-ul pentru sistemele informatice nu se oprete aici. Exist un numr mare de programe ce vor fi prezentate n continuare. 2.2.1. Programe utilitare Programul utilitar este un program mai mic ce aduce mbuntiri fa de lucrul n sistem de operare, realiznd diverse operaii simple sau mai complexe asupra suporturilor de memorie sau datelor aflate pe aceste suporturi. Operaiile pe care le fac programele utilitare pot fi realizate i direct din sistemul de operare de ctre specialiti, lucrnd cu ntreruperile, gestionnd memoria mai bine, ns ele se realizeaz foarte greu de ctre un nespecialist. De altfel, apariia programelor utilitare a dus la dezvoltarea i perfecionarea sistemelor de operare, astfel nct aceste sisteme au integrat treptat i multe programe utilitare (gen Notepad, Wordpad, Paint etc.). Facilitile pe care le-au adus programele utilitare referitor la hard disc au fost legate n primul rnd de posibilitatea de afiare n regim text sau grafic a structurii pe foldere i subfoldere a acestuia. Afiarea sub form arborescent (tree) cu ramificaiile detaliate sau nu, cu relaiile dintre fiiere i structur, afiarea n ferestre cu posibilitatea rapid de copiere, mutare dintr-o fereastr n alta, selectarea fiierelor mult mai rapid, afiarea coninutului unui fiier cu posibilitatea editrii lui, dac dimensiunea acestuia nu este prea mare, vizualizarea fiierelor i directoarelor ordonate dup diverse criterii: nume, extensie, lungime, dat sunt numai cteva faciliti pe care le-au adus programele utilitare. Tot cu aceste programe se mai pot crea meniuri proprii n care pot fi introduse comenzi ntlnite frecvent, executarea lor fcndu-se prin selectarea opiunii din meniu sau prin scurtturi (shortcuts). Sunt de fapt primul pas fcut spre sistemele de operare vizuale, cu interfee prietenoase ca WindowsNT, Macintosh, Next. Din categoria acestor programe utilitare amintim: Norton Desktop (Symantec); Norton Antivirus (Symantec); Dashboard (Hewlett-Packard) etc. Ele aduc i alte faciliti referitoare la date, fiiere cum ar fi: protejarea prin parole a fiierelor, folderelor, discurilor, compactarea sau arhivarea datelor pentru a mri spaiul pe disc, copierea i tergerea fiierelor automat (backup) la un anumit moment din zi curarea discului i a memoriei de eventualii virui. Unele programe utilitare pot reface informaii terse (fiiere, foldere) sau pierdute prin formatare accidental, faciliti numite undelete i unformat. Defragmentarea este o alt operaiune prin care se grupeaz spaiul liber de pe disc n mod compact (la nceput sau la sfrit) astfel nct accesul la un fiier sau folder s fie mult mai rapid ca i cutarea unui spaiu liber pentru crearea unui fiier sau folder. Gestionarea memoriei mult mai eficient se poate face prin programe utilitare, ce pot mri memoria convenional de 640 Kb prin utilizarea memoriei de la 640 K n sus (expanded & extended memory), astfel nct cantitatea de date ce poate fi prelucrat nemaifcndu-se acces la hard-disk crete substanial i odat cu aceasta timpul de execuie se micoreaz. Tot pentru mrirea vitezei exist utilitare ce pot anticipa ce parte a discului va fi folosit i pot ncrca n memorie informaiile din aceast zon (chaching). Probleme de comunicaii pot fi rezolvate i ele cu ajutorul programelor utilitare. Astfel de utilitare sunt: Norton Utilities; PCAnywhere (Symantec); After Dark (Berkeley Sys.); QEMM (Quarterdeck);
Fastback (Fifth Generation). Odat cu dezvoltarea platformei Windows au aprut utilitare ce pot crea iconuri, cursoare de mouse, meniuri, dialoguri, acceleratoare etc. 2.2.2. Pachete integrate Folosirea eficient a unui calculator necesit cel puin folosirea unui procesor de texte, unui program de calcul tabelar, a unei baze de date i eventual a unui procesor de imagine. Cum majoritatea utilizatorilor au nevoie de cte un program din fiecare, multe firme ofer pachete coninnd fie o colecie de programe care sunt vndute i separat, fie un produs integrat care ofer facilitile de procesare de texte, calcul tabelar, grafic i baze de date simple. Acestea se numesc pachete integrate i au avantajul comunicabilitii ntre produse, uniformitii stilistice i nu n ultimul rnd al preului mai sczut. Dintre acestea se poate aminti: MS Office al firmei Microsoft; Smart Suite al firmei Lotus; WordPerfect Office al firmei Corel; Star Office al firmei Sun; Open Office al Open Office Org; Aproape toate pachetele integrate ofer i programe de comunicaii de pot electronic, organizatoare etc. i folosesc Windows-ul, ceea ce asigur o portabilitate i compatibilitate a aplicaiilor dntr-un produs n altul. 2.2.3. Proiectare asistat pe calculator Programele de proiectare asistat de calculator CAD (Computer Aided Design) sunt programe de grafic, mai pretenioase, n care precizia desenrii joac un rol foarte important. Se pot proiecta obiecte tridimensionale asupra crora se pot aplica secionri, scalri, rotaii, compuneri i descompuneri de obiecte. Vizualizarea obiectelor poate fi fcut n cele mai mici amnunte i din diverse poziii. Produsele din aceast categorie dispun de bogate biblioteci grafice, cu multe exemple, cu imagini ce pot fi adugate n bibliotec, cu stiluri de linii, cu pattern-uri pentru hauri i suprafee. Ustensilele de care dispun sunt uor accesibile cu ajutorul mouse-ului, se poate folosi cu uurin compasul, linia, guma, lupa i multe altele, printr-o simpl apsare a unui buton dintr-o tabel de instrumente (tools). Posibilitatea inserrii textului n imagine precum i importul de imagini de tip raster sunt alte faciliti ce fac din programele de proiectare o soluie produciv pentru crearea rapid de desene, rapoarte, schie, documente. Dintre aceste programe de proiectare asistat se remarc: Auto CAD for Windows, Generic CAD, Auto Sketch (AutoDesk) Drafix CAD (Foresight); Design CAD 2D/3D (American Design); Toolbox Professional; Auto Architect etc. 2.2.4. Programe de gestionare a documetelor i de birou Programele DMS (Document Management System) sunt programe specializate n organizarea i stocarea documentelor de tip text sau imagine. Exist sisteme DMS destinate n princip al prelucrrii
de texte prin stocarea lor ntr-o arhiv indexat i sisteme DMS destinate prelucrrii de imagini cu stocarea acestora pe discuri optice. ntr-un sistem DMS se definesc mai nti profilurile documentelor, adic informaii ce definesc coninutul unui document, tipul acestuia, cine l-a creat i cnd, unde este stocat, legturi cu alte documente. Indexarea se poate face dup aceste profile sau dup cuvinte cheie existente n documente. Funcia principal a unui DMS este regsirea rapid a documentelor i vizualizarea acestora. Dac specificaiile nu sunt complete atunci se furnizeaz lista documentelor ce satisfac condiiile de interogare, pe baza indexului profilelor sau chiar cuvintelor din documente. Un sistem DMS este destinat lucrului n reea, deoarece la un document trebuie s aib acces, eventual n acelai timp, mai multe persoane precum i faptului c un document poate fi realizat de ctre mai multe persoane. Apar astfel probleme de actualizare a versiunilor documentelor, modificri ireconciliabile de ctre persoane diferite, securitate i control asupra accesului la un document, ce sunt rezolvate n mod diferit de la program la program. Calea ctre biroul fr hrtii este deschis prin aceste DMS, dar ele necesit n general un scanner, un PC puternic, o imprimant rapid, discuri optice n cazul prelucrrii de imagini, ceea ce poate duce la un cost destul de ridicat, deocamdat! De altfel probleme legate de recunoaterea optic a caracterelor (OCR), arhivare, dezarhivare rapid sunt probleme de actualitate n domeniul DMS i care dau o imagine fantastic viitorului. Din familia sistemelor DMS se pot remarca: Auto EDMS al firmei ACS Telecom; Notes 3.0 al firmei Lotus; Apple Search al firmei Apple; Acrobat al firmei Adobe. Produsele PIM (Personal Information Manager) includ un planificator de activiti corelat cu un calendar, o agend de adrese, cu posibilitatea de conectare la telefon prin plac de fax sau modem, notesuri pentru diverse documente, dicionare etc. Un PIM este un produs uor de folosit, rapid n utilizare i nu necesit un spaiu mare pe disc. Este un program ce st resident n memorie, adic poate fi accesat oricnd se dorete, chiar dac este activ un alt program. Manipularea produsului se face de obicei cu ajutorul mouse-ului ca de exemplu rsfoirea unor pagini ce apar pe ecran, selectarea unor litere din repertoar. n prezent multe din funciile acestora se regsesc n programele de e-mail (Outlook, de exemplu). Acestea pot importa date dintr-o baz de date sau spreadsheets sau interschimba date, informaii cu un alt utilizator de PIM. Mai poate conine agende cu cri de vizit, cu organizarea timpului pe zile i ore, avnd posibilitatea realizrii unor legturi ntre persoane i notesul cu activiti sau ntlniri, anunrii programate n cazul unor evenimente ca aniversri, activiti importante. Dintre aceste produse se pot remarca: Act al firmei Symantec (CSI); Organizer al firmei Lotus. Posibilitatea listrii la imprimant, n diverse formate standard sau definite de utilizator, a oricrei componente a PIM-ului, introducerii parolelor de acces, personalizrii agendei prin notaii proprii, inserrii de poze i imagini n agend sunt i alte faciliti care fac din PIM instrumentul ce poate elibera un birou de teancul de hrtii, agende, cri de vizit etc. 2.2.5. Shareware i public domain Oferta shareware const din programe diverse testate sau netestate, disponibile la preuri foarte mici, cu posibilitatea ncercrii lor nainte de a le cumpra. Dac programul se dovedete a fi util atunci este obligatorie virarea unei sume modice n contul autorului produsului, nu al vnztorului, putnd primi
astfel documentaii i versiuni mbuntite ale programului respectiv. Piaa produselor shareware cuprinde practic toate domeniile, cum ar fi: programe utilitare, jocuri, programe educaionale, aplicaii grafice, limbaje de programare, spreadsheets, procesoare de texte, baze de date etc. Oferta public domain const din produse software la preuri foarte mici pe care cumprtorul le poate da prietenilor sau chiar le poate revinde fr nici o restricie. Ce se urmrete prin produsele shareware i public domain? n primul rnd intrarea n lumea bun a informaticii, de asemenea promovarea produselor, ctigarea unui numr mare de clieni, virtuali cumprtori i ai unor alte produse ale aceleai firme (nu obligatoriu tot produse shareware).
2.3. Clasificarea sistemelor informatice

Clasificarea sistemelor informatice se face n funcie de anumite criterii, i anume: [Lungu&alt, 1995], [Oprea, 1999] 1. n funcie de domeniul de utilizare, acestea se clasific n patru grupe, care sunt prezentate n urmtoarea figur.
Conducerea activitilor organizaiilor economicosociale
SISTEME INFORMATICE
pentru
Conducerea proceselor tehnologice
Cercetare tiinific i proiectare tehnologic
Activiti speciale
a. Specific
sistemelor informatice pentru conducerea activitilor organizaiilor economico-sociale este faptul c datele de intrare, de regul, sunt fumizate prin documente
ntocmite de om, iar datele de ieire sunt fumizate de ctre sistem tot sub form de documente (liste, rapoarte etc.) pentru perceperea acestora de ctre om. b. Spre deosebire de acestea, sistemele informatice pentru conducerea proceselor tehnologice se caracterizeaz prin aceea c datele de intrare sunt asigurate prin intermediul unor dispozitive automate care transmit sub form de semnale (impulsuri electronice) informaii despre diveri parametri ai procesului tehnologic (presiune, temperatur, umiditate, nivel), iar datele de ieire se transmit, de asemenea, sub form de semnale unor organe de execuie, regulatoare, care modific automat parametrii procesului tehnologic. Se execut n acest fel controlul i comanda automat a procesului tehnologic. Astfel de sisteme sunt folosite n locurile n care este periclitat intervenia n mod direct a factorului uman. Exemple de asemenea sisteme sunt cele pentru laminarea oelului, pentru procesele din petrochimie, pentru fabricarea cimentului, a hrtiei, centrale nucleare etc. n mod firesc apar diferene ntre obiectivele celor dou categorii de sisteme, cele pentru conducerea proceselor tehnologice avnd ca obiective mbuntirea randamentului agregatelor, urmrirea siguranei n funcionare, creterea indicatorilor de calitate a produselor, mbuntirea altor indicatori tehnico-economici.
c. Sisteme informatice pentru activitatea de cercetare tiinific i proiectare tehnologic asigur automatizarea calculelor tehnico-inginereti, proiectarea asistat de calculator i alte faciliti neesare specialitilor din domeniile respective. d. Sistemele informatice speciale sunt destinate unor domenii specifice de activitate, ca exemplu: informare i documentare, tehnico-tiinific, medicin etc. 2. Un alt criteriu de clasificare al sistemelor informatice economice este n funcie de nivelul ierarhic ocupat de sistemul economic n structura organizatoric a organizaiei, conform cruia avem urmtoarea clasificare: a. Sisteme informatice pentru conducerea activitii la nivelul organizaiilor economice. Acestea pot fi descompuse n subsisteme informatice asociate funciunilor organizaiilor economico-sociale sau chiar unor activiti. b. Sisteme informatice pentru conducerea activitii la nivelul organizaiilor economicosociale cu structur de grup. n aceast categorie sunt incluse sistemele informatice la nivelul regiilor autonome. c. Sisteme informatice teritoriale. Sunt constituite la nivelul unitilor administrativteritoriale i servesc la fundamentarea deciziilor adoptate de ctre organele locale de conducere. d. Sisteme informatice pentru conducerea ramurilor, subramurilor i activitilor la nivelul economiei naionale. Se constituie la nivelul ramurilor, subramurilor i activitilor individualizate n virtutea diviziunii sociale a muncii i specificate n clasificarea economiei naionale. Sunt elaborate i administrate de ministerele, departamentele sau organele care au prin lege sarcina de a coordona metodologic grupele respective de activiti. Principala lor funcie const n fundamentarea i reglarea echilibrului dezvoltrii economico-sociale n profil de ramur. Aceste sisteme vor trebui s realizeze elaborarea de variante a proiectului de plan n profil de ramur, ncrcarea optim a capacitilor de producie, folosirea intensiv a mainilor, utilajelor i instalaiilor, urmrirea i controlul realizrii sarcinilor de plan i a celor privind calitatea produciei, perfecionarea produselor i a tehnologiilor, nnoirea produciei i asigurarea de noi produse, utilizarea superioar a potenialului material i uman din ramura respectiv. e. Sisteme informatice funcionale generale ce au ca atribut principal faptul c intersecteaz toate ramurile i activitile ce au loc n spaiul economiei naionale, furniznd informaiile necesare coordonrii de ansamblu i sincronizrii lor n procesul reproduciei din cadrul economiei de pia. n aceast categorie sunt cuprinse sistemele pentru planificare, statistic, financiar-bancar etc. 3. Un alt criteriu de clasificare al sistemelor informatice este acela dup aportul acestuia n actul decizional. Decidentul dintr-o unitate are prin sistemul informatic un puternic suport pentru fundamentarea deciziilor sale. Acest suport implementeaz modele matematico-economice din domeniul specific de activitate sau cu caracter general. Este situaia clasic de realizare a sistemelor informatice ca asistent al decidentului. Acestea execut o mic parte din activitatea decidentului, rolul lor important fiind de culegere i prelucrare automat a datelor. Este perioada de pn n jurul anului 1970, cnd dou discipline au venit n sprijinul tiinific al sistemului informatic-decizional: cercetrile operaionale i teoria deciziei. n aceast perioad apar i primele sisteme suport de decizie (SSD) ca sisteme pentru prelucrarea automat a datelor mpreun cu sistemele de luare a deciziilor. Anii 1970 au nsemnat o cretere puternic a fluxului informaional n toate domeniile de activitate, a bazelor de date i a teleprelucrrii. Acestea au permis prelucrarea unui volum mai mare de date i o comunicaie mai rapid i mai eficient. Rolul sistemului informatic crete n raport cu decidentul, ajungnd s fie un colaborator al acestuia. De multe ori, aceste sisteme
informatice execut o parte nsemnat din activitatea decidentului evolund, astfel spre sisteme suport de decizie. ncepnd cu anii 1970, bazele de date au evoluat spre relaional i distribuit, iar reelele de calculatoare locale i generale au devenit curente. Informaia care se prelucreaz se diversific foarte mult, volumul de date este tot mai mare, iar complexitatea prelucrrilor de asemenea. Sistemele informatice ncep s execute mare parte din activitatea de rezolvare a problemelor de decizie, devenind experte n domeniu, evolund astfel spre sisteme expert (SE). Volumul de date mare i complexitatea deosebit a datelor care circul pe magistralele (reelele) informaionale internaionale n momentul de fa tind s sufoce sistemele informatice bazate pe relaional. Abordarea orientat obiect, precum i realizarea de baze de cunotine, pe maini tot mai puternice, tind s rezolve aceast problem. Sistemele expert, precum i sistemele suport de decizie sunt de fapt sisteme informatice dedicate. Iat cteva aspecte comune i deosebiri dintre ele: a. Tehnologia de realizare se pstreaz n mare parte pentru toate cele trei tipuri de sisteme. Pe de o parte, SSD i SE au preluat n metodologia lor de realizare majoritatea activitilor din metodologia de realizare a SI, adoptnd o parte din ele. Pe de alt parte, metodologia de realizare a i a evoluat mult odat cu apariia SSD i SE, prelund o serie de elemente de simplitate, flexibilitate, precum i stilul de lucru n pai mruni i reluri succesive. Ideea ca un sistem informatic, ca dealtfel orice produs informatic, se realizeaz "la cheie" prin etape care odat realizate nu se mai pot relua, nu mai este agreat. Stilul de lucru de la sistemele expert care presupune realizarea unei versiuni care nu este nici ultima, nici cea mai bun, urmnd apoi s se realizeze versiuni succesive pentru perfecionare i dezvoltare, este tot mai mult utilizat i n realizarea sistemelor informatice. b. Toate folosesc abordarea sistemic pentru studierea i rezolvarea problemelor. Aceasta este o cale eficient pentru nvingerea complexitii i pstrarea coerenei. Abordarea sistemic presupune o serie de caracteristici n procesul de cunoatere, caracteristici care se regsesc la realizarea tuturor celor trei tipuri de sisteme. Aceste caracteristici sunt: extragerea sistemului studiat se face din mediul nconjurtor; definirea problemei i descrierea ei se face cantitativ i/sau calitativ; se definesc mijloacele posibile pentru rezolvarea problemei; se formuleaz diferite variante de rezolvare a problemei; se compar variantele i se alege cea mai bun (cea care satisface cel mai bine cerinele). c. Modul de rezolvare al problemelor pstreaz direcii comune care caracterizeaz sistemul uman de prelucrare i evaluare a informaiei. Acest lucru este firesc n SSD i SE, i se accentueaz n i prin abordarea orientat obiect. n acest sens, se mbin aspectele descriptive cu cele imperative, neprocedurale cu cele procedurale, n funcie de sistem punndu-se accentul pe unul sau altul dintre aceste aspecte. Modulul rezolutiv se bazeaz n special pe raionamente, dar i pe algoritmi n SE i se bazeaz n special pe algoritmi, date i raionamente n SSD i SI. Raionamentul se bazeaz pe modelul logic i nu pe cel fizic, ceea ce nseamn c primeaz relevana i mai puin precizia. Acest lucru este valabil att n mecanismul de inferen din SE, ct i n procesul decizional din SSD. n SI, n modelul prelucrativ, conteaz mai mult precizia i mai puin relevana. Aplicaiile cu baze de cunotine sunt n ultim instan aplicaii informatice care permit rezolvarea de probleme dificile prin simularea raionamentului uman asupra unor cunotine specifice unui domeniu dat. d. Cele trei sisteme, dei au arhitecturi diferite, pstreaz i elemente comune. Toate au colecii de date care sunt fiiere sau baze de date n SI, baze de cunotine n SSD (baza de date i baza de modele) i SE (baza de cunotine i modele). n plus fa de SI, SSD conin o baz de module care este de fapt o bibliotec de module permanente sau de uz temporar. Acestea pot fi ale utilizatorului sau realizate de firme specializate. Modulele operative, tactice sau strategice, de calcul sau analiz etc. Dimensiunile acestor module pot fi de la o singur relaie pn la foarte multe. Legat de aceast baz de module, SSD va conine un mecanism de
construire sau generare a modulelor, va avea posibilitatea s restructureze un modul, s-l actualizeze i s opereze asupra modulelor pentru a obine rapoarte de ieire. n loc de coleciile de date din SI, SE conin o baz de cunotine n care se descriu obiectele din lumea real. Ea conine fapte (axiome) i reguli (care pot descrie i modele). Att SSD, ct i SE au componente pentru nvare care achizioneaz noi cunotine. Aceast component lipsete ca atare n SI, dei sunt ncercrii n acest sens de a fi inclus. De asemenea, toate sistemele conin interfee cu utilizatorul care tind s devin tot mai prietenoase, uor de folosit i interactive. Aceast component tinde s depeasc jumtate din codul program generat, n toate cele trei sisteme. Tendina este dat de mainile interactive actuale i de societatea informaizat care determin o utilizare n mas a calculatoarelor. Dialogul dat de interfa trebuie s fie ct mai "natural" pentru a elimina bariera psihologic dintre om i main. Stilul de dialog poate fi ntrebare-rspuns, limbaj de comand, meniu, videoformat, ferestre etc., la care se adaug facilitile oferite de platformele multimedia (dac acestea sunt disponibile). e. Toate cele trei sisteme ajut decidentul n activitatea sa, i fundamenteaz decizia. Contribuia fiecrui tip de sistem la sprijinul decidentului, n fundamentarea deciziilor este prezentat n tabelul 1.1. Tabelul 1.1. Contribuia fiecrui tip de sistem la procesul decizional Tip Partea executat din activitatea Ajutor pentru decident sistem decidentului SI Asistent O mic parte Colaborator O parte nsemnat SSD SE Expert O mare parte f. Problemele rezolvate cu cele trei tipuri de sisteme sunt de natur diferit, dei au i elemente comune (provin din lumea real etc.) Dac ntr-o problem criteriile sunt preponderent cantitative, iar caracteristicile problemei se formuleaz cantitativ, modelarea se face foarte bine algoritmic i va rezulta un SI. Dac ns exist formulri mai puin cantitative se tinde spre SSD sau SE, care ns .nu exclud folosirea algoritmilor. Pentru problemele complexe n condiii de incertitudine, se pornete conceptual, dar i practic, de la baze de date clasice spre baze de cunotine. Acestea au la baz cunotine incomplete, inconsistente, incerte, imprecise, ambigui. Pentru fiecare dintre aceste categorii de cunotine exist o logic nestandard de care se ine cont n abordarea problemei. Acest lucru se trateaz bine n SSD i SE, i foarte greu sau imposibil de tratat n SI. Din analiza de mai sus rezult evoluia n anumite condiii a i spre SSD. La SE evoluia se constat n ceea ce privete conceptele (sistem, componente, modele, obiecte etc.), metodologia de realizare (principalele activiti, metode, tehnici etc.), soluii software de implementare (limbaje, tehnici de programare, inginerie software etc.). Pe de alt parte, din punct de vedere al organizrii datelor, se constat evoluia bazelor de date relaionale spre cele orientate obiect i spre bazele de cunotine. Simplificarea modelului relaional i mbuntirea lui a condus spre modelul orientat obiect. De asemenea, reprezentarea prin perechile A-V (atribut-valoare) din relaional o regsim i n bazele de cunotine (exemplul din limbajul Prolog). 4. Din punct de vedere al organizrii datelor sistemele informatice se clasific n: a. SI care au coleciile de date organizate n fiiere. Fiierele pot fi cu organizare clasic (secveniale, indexat-secveniale, relative) sau cu organizare special. Acest mod de organizare a datelor este tot mai rar utilizat astzi, i el este acceptate doar pentru sisteme mici. n orice caz, aceste sisteme trebuie s foloseasc i fiiere care permit accesul direct pentru uurina i rapiditatea manipulrii datelor. n cadrul acestor sisteme informatice datele se introduc de la tastatur n sistemul informatic ori de cte ori este nevoie, crendu-se cte un fiier pentru fiecare tip de prelucrare necesar sistemului. b. SI care au colecii de date organizate n baz de date. Pentru acest lucru se folosete un model de date care poate fi arborescent, reea, relaional sau orientat obiect i un SGBD
adecvat. Cel mai utilizat model este cel relaional, dar n ultimii ani sunt utilizate din ce n ce mai mult bazele de date relaional obiectuale. Majoritatea i sunt de acest tip datorit avantajelor oferite de bazele de date n crearea i manipularea coleciilor de date. c. SI mixte care au colecii de date organizate n baz de date, dar i n fiiere. Pot aprea i astfel de situaii n realizarea unui sistem informatic, n sensul c pe lng baza de date sunt necesare i o serie de fiiere relativ independente prelucrate din limbaje de programare, n afara SGBD-ului. Astfel de cazuri apar mai ales atunci cnd se colaboreaz cu alte sisteme sau aplicaii informatice (procesoare de text, de imagini, de calcul tabelar, e-mail etc.). Aceste criterii nu sunt singurele utilizate n clasificarea sistemelor informatice. Astfel, alte criterii au n vedere: Modul de introducere a datelor n sistemul informatic. Modul de prelucrare a datelor generate de sistemele economice. Obiectivele urmrite etc.
Curs 3 Stadiul actual i tendinele dezvoltrii sistemelor informatice

n ultimii ani asistm la una dintre cele mai importante transformri din istorie ale infrastructurii tehnologice a societii. Aceast schimbare const de fapt n adugarea unui nou substrat n infrastructura tehnologic, substrat care este uzual denumit tehnologia informaiei. n acest nou substrat se evideniaz n mod decisiv informatica. Extinderea ntr-o msur din ce n ce mai mare a tehnologiei informaiei a devenit posibil datorit progreselor rapide i importante ale microelectronicii. Aceast extindere este pe cale de a produce o schimbare major n societatea noastr, i anume, trecerea de la orientarea industrial, n care accentul se pune pe main i energie, la o nou orientare, informaional, n care accentul se pune pe robot i informaie. Este evident c i n continuare maina i energia vor juca un rol important, fundamental, n societatea informaional, dar pentru noile maini, pentru noile industrii, ca i pentru celelalte activiti ale omului, devin eseniale tehnologiile informatice care au la baz electronica, informatica i comunicaiile moderne. [Lungu&alt, 2003] Informatizarea activitilor economico-sociale a cunoscut profunde transformri. n cele ce urmeaz se enumer cteva din schimbrile i tendinele ce au loc n practica dezvoltrii sistemelor informatice. 1. Se manifest n mod clar o tendin spre divizarea costurilor software-ului sistemelor informatice. Reducerea costurilor sistemelor informatice se datoreaz, pe de o parte, reducerii costurilor hardware-ului, iar pe de alt parte, reducerii costurilor software-ului. n ceea ce privete componenta software, putem spune c cu ani n urm nu erau aa de multe produse software disponibile pe pia. Modul obinuit de implementare a sistemelor informatice era de a programa de unul singur software-ul necesar. Fiecare implementare tindea s fie alctuit din software-ul pentru un anumit scop. Acest mod de lucru era extrem de scump pentru c nu se obineau reduceri de costuri provenite din generalizarea pe scar larg a sistemului. Costurile de proiectare, realizare, meninere i calitate pentru fiecare component ar trebui suportate doar de un singur utilizator al sistemului. n prezent se manifest o tendin clar n dezvoltarea sistemelor informatice bazate tot mai mult pe platformele software de nivel nalt. O platform software corespunde unei platforme de aplicaii i conine funcii software de baz i funcii specifice aplicaiei companiei. Prin funciile software de baz se definesc i se rezolv problemele comune aplicaiei n proporie de circa 80-90%, iar prin software-ul specific aplicaieie se definesc proprietile comportamentale suplimentare companieie. O astfel de abordare ofer posibilitatea generalizrii i implementrii sistemelor n mai multe uniti economice, cu efecte imediate de divizare i reducere a costurilor pe unitate de implementare. Ideea de baz a unei platforme comune de aplicaii este ntr-adevr veche. Noua invenie este c, n sfrit, ideea a ajuns s fie implementat. 2. Se manifest o intens tendin spre tehnologia sistemelor informatice bazate pe reele de calculatoare. Creterea complexitii, varietii aplicaiilor i apariia de noi produse informatice cu un raport pre/performan din ce n ce mai avantajos au fcut necesar i rentabil conectarea ntre ele a calculatoarelor n cadrul unor reele care constituie la ora actual suportul cel mai adecvat pentru teleinformatic. O importan remarcabil n dezvoltarea reelelor a avut-o Internet-ul (cu semnificaia de reea a reelelor) care a oferit posibilitatea accesului nelimitat la diverse tipuri de informaii, precum i comunicarea ntre diverse persoane de pe ntreaga planet conectate la Internet.
Stadiul actual i tendinele dezvoltrii sistemelor informatice 2727
Tendinele din domeniul reelelor de calculatoare cuprind diverse aspecte, cum ar fi apariia i dezvoltarea de noi protocoale i medii de comunicaie ce permit viteze de transport de ordinul gigabiilor/sec, dezvoltarea fr precedent a comunicaiilor fr fir, dezvoltarea reelelor de satelii, a accesului la distan n scopul unor operaiuni de comer electronic sau pentru diverse tranziii electronice on-line. 3. n domeniul organizrii datelor se manifest tendina spre baze de date orientate obiect. Structurile clasice de date bazate pe text i valori numerice fie se dovedesc insuficiente, fie complexitatea lor depete posibilitile de stocare i prelucrare oferite de tehnologiile clasice. Aplicaiile asociate cu disciplinele tehnologice, cum ar fi proiectarea asistat de calculator, sistemele informatice geografice i sistemele bazate cunotine, presupun stocarea unor cantiti mari de informaii cu o structur complex. Aceste aplicaii necesit suport pentru tipurile de date care nu pot fi reprezentate n sistemele clasice. Unele aplicaii informatice solicit monitorizarea unor desene formate din grupuri de elemente complexe ce trebuie s fie combinate, separate, suprapuse i modificate astfel nct s permit elaborarea unor variante de proiect. Totodat, orientarea spre multimedia aduce elemente noi n lumea informaticii. Grafica, imaginea fotografic, imaginea video, sunetul, muzica nu pot fi tratate n aceeai manier cu a structurilor tabelare de denumiri i numere. Dac eforturile de extindere a tehnologiilor actuale n domeniul colectrii, stocrii i prelucrrii acestor noi tipuri de informaii ca elemente singulare sunt tot mai adesea finalizate cu succes, nu acelai lucru se poate spune despre administrarea corespunztoare a unor colecii de astfel de date. Bazele de date clasice sau relaionale ofer prea puin suport teoretic i practi pentru tipurile neconvenionale de date. Bazele de date orientate obiect permit crearea de obiecte complexe din componente mai simple, fiecare avnd propriile atribute i propriul comportament, n acest fel ele reuesc s ofere soluii pentru problemele i aplicaiile amintite anterior. 4. Sisteme informatice de tip nou. Pentru aplicaiile tradiionale pentru care au fost concepute, sistemele relaionale satisfac cerinele acestora. Descrierea datelor sub form de tabele corespunde bine tipului de informaii manipulate de aceste aplicaii. O dat cu scderea costului calculatoarelor i creterea puterii lor de calcul au aprut noi aplicaii care manipuleaz cantiti mari de date. Printre acestea enumerm: sisteme pentru proiectarea asistat de calculator, sisteme multimedia, sisteme deschise. Aceste aplicaii exist deja i reprezint o pia foarte important pentru sistemele de gestiune a bazelor de date (SGBD). Majoritatea dintre aceste aplicaii nu utilizeaz ns un SGBD, ci sunt construite cu sisteme dedicate. Acest lucru se datoreaz faptului c un sistem de gestiune a bazelor de date relaional SGBDR nu ofer funcionalitile necesare. Noile generaii de baze de date vor trebui s in cont nu numai de aplicaiile tradiionale, dar i de noile aplicaii. Utilizarea unui SGBD standard n locul unui SGBD dedicat va permite reducerea considerabil a costului de punere n funciune a acestor noi aplicaii. Este foarte probabil c alte tipuri noi de aplicaii vor aprea. Din aceast cauz noile generaii de SGBD vor trebui s aib implementat conceptul de extensibilitate. Adic ele trebuie s fie capabile s administreze nu numai tipurile de aplicaii identificate la un moment dat, ci s se adapteze la alte tipuri de aplicaii care nu au fost prevzute iniial. a. Sisteme de proiectare asistat de calculator. Aplicaiile genereaz un ansamblu de faze (activiti) pentru realizarea unui produs. Datele manipulate sunt adesea foarte complexe, descrierea unei componente fiind dependent n mare msur de celelalte componente ale aceluiai produs. Se regsete aici i o parte important a informaiei de tip regsire documentar. b. Sisteme multimedia. Aplicaiile de acest nou tip au drept caracteristic aceea c administreaz datele ntr-un mod netradiional. Exemplele cele mai cunoscute sunt aplicaiile care administreaz imagini i sunet pe lng text i grafic. Exist deja acum aplicaii comerciale care folosesc astfel de date, cum ar fi, de exemplu, aplicaiile meteorologice. Acest
tip de aplicaii se caracterizeaz printr-un volum foarte mare de date tratate. Imaginile sunt date foarte voluminoase care necesit un suport de stocare i prelucrare performant. Tehnologia discurilor optice numerice este adaptat acestor aplicaii. Un SGBD care suport aplicaii multimedia trebuie s foloseasc tratamentul clasic asupra imaginilor i s administreze legturile de tot felul dintre acestea De exemplu, ntr-o aplicaie meteorologic trebuie cutate printre imaginile stocate pe toate cele care ajut la detectarea unui ciclon. Pentru o astfel de operaie trebuie folosit tehnica de cutare i acces classic ntr-o baz de date, precum i tehnica specific de tratare a imaginilor. Aceleai observaii sunt valabile i pentru tehnica specific de tratare a sunetului. Pentru aplicaiile multimedia este deci nevoie de o integrare tehnologic nou cu cea tradiional. c. Sisteme deschise. Expresia sisteme deschise corespunde ea nsi unui concept vag. Ideea este de a aduce un plus de flexibilitate organizaiilor prin aplicaiile care se dezvolt pentru ele. Supleea (flexibilitatea) n dezvoltarea i exploatarea sistemelor aferente unei uniti se realizeaz prin: paleta larg de diferite tipuri de periferice i platforme ce pot fi interconectate; uurina de utilizare a instrumentelor de proiectare a sistemelor deschise; posibilitatea interconectarii aplicaiilor cu alte aplicaii dezvoltate pentru platforme diferite. La sistemele deschise totul ncepe cu problema standardelor. Anumite standarde sunt stabilite de comitete naionale i internaionale, altele sunt impuse de grupurile de proprietari sau vnztori, altele exist pur i simplu pentru anumite produse care sunt larg utilizate (exemplu: o versiune standard de C a fost acceptat de un comitet internaional, MOTIF este o interfa promovat de un grup de ofertani ncercnd s normalizeze Unix, Windows este un produs impus de proprietar - Microsoft etc.). Standardele proprietarilor sau productorilor sunt acceptate mai uor dac produsul ofer faciliti de interconectare cu alte produse standard (exemplu: limbajul standard de regsire din bazele de date - SQL). Pentru a se evalua nivelul de deschidere al unui produs informatic i a decide dac acesta poate fi considerat un instrument pentru elaborarea de aplicaii acesta trebuie s aib anumite caracteristici. Singurele instrumente cu adevrat dechise sunt limbajele de programare. d. Sisteme pentru comerul electronic. Ca urmare a extinderii Internet-ului, se manifest un interes deosebit pentru o serie de noi aplicaii dintre care comerul electronic ocup un loc nsemnat. Comerul electronic presupune o metodologie modern care se adreseaz folosirii tehnologiei informaiei ca un potenial esenial al afacerii. n contextul n care Internet-ul poate fi privit ca un univers informaional, comerul electronic apare ca un nou mare orizont i trebuie doar s se tie modalitile de valorificare deplin a acestui potenial. Dei comerul electronic este mai mult ca niciodat o problem de afacere strategic, viitorul afacerii va depinde de abilitatea de a folosi interschimbul electronic de date. Sintetiznd se poate spune c tendinele n dezvoltarea software sunt: 1. Dezvoltarea de aplicaii, pachete integrate ieftine i care se pot utiliza n mai multe domenii. 2. Pachete software care utilizeaz resursele de reea, permit conlucrarea la aceleai documente. 3. Integrarea software-ului cu Internet-ul. 4. Programe uor de utilizat ce folosesc tehnologii obiectuale orientate grafic, inteligena artificial n scopul de a utiliza limbajul natural pentru a uura programarea. 5. Dezvoltarea de experi-asisteni n cadrul sistemelor expert ce nglobeaz inteligena artificial.
3.1. Evoluia sistemelor informaionale n cadrul firmelor

n ultimele cinci decenii s-au nregistrat schimbri semnificative (tabelul nr. 1) n configuraia structurilor informaionale ale firmelor care au devenit n ultima perioad de timp mai informaizate. [Nistor&alt, 2003] Pn n anii 1960, rolul sistemelor informaionale era simplu: utilizarea lor pentru nregistrarea operaiunilor legate de funciuni critice i de procesare a tranzaciilor. La sfritul anilor 1960 apare conceptul de sistem informaional managerial, care se va transforma cu timpul n sistem informatic managerial. Rolul acestuia era de a furniza rapoarte predefinite managerilor, rapoarte care conineau informaiile de care aveau nevoie n fundamentarea deciziilor. Tabelul nr.1 Atribuii tehnice Control managerial Inima aciunilor instituionale Funcii 1950 1960-1970 1980-1990 Perioada n perioada 1970-1980 s-a remarcat c rapoartele predefinite furnizate de sistemele informaionale manageriale (Management Information System MIS) erau insuficiente managerilor pentru luarea deciziilor, n condiiile n care au intervenit schimbri semnificative n condiiile de mediu, inclusiv la nivelul pieelor de referin. Astfel a aprut conceptul de sisteme suport a deciziilor (Decision Suport Systems DSS). Aceste sisteme ofereau utilizatorilor finali, n special managerilor, un suport interactiv n procesul de luare a deciziilor. n plus, aceste sisteme erau mai bine adaptate diferitelor stiluri manageriale. n perioada 1980-1990 s-au evideniat noi roluri ale sistemelor informaionale. Aceast perioad este caracterizat de dezvoltarea microcalculatoarelor, a pachetelor de aplicaii software, i a reelelor de telecomunicaii. Acum, utilizatorii finali pot folosi resursele informaionale ca suport necesar ndeplinirii sarcinilor, n loc s atepte un suport indirect al serviciilor informatice din cadrul departamentelor. S-a constatat c majoritatea managerilor nu utilizau n mod direct nici rapoartele furnizate de sistemele informaionale manageriale (MIS), nici modelele analitice de suport a deciziilor furnizate de sistemele suport a deciziilor (DSS). Astfel a aprut conceptul de sisteme informatice executive (Executiv Information System EIS). Aceste sisteme informatice furnizeaz managerilor informaiile critice exact cum le doresc acetia i n formatul pe care l prefer. Tot n aceast perioad i n special la sfritul anilor 1980 au aprut i s-au dezvoltat aplicaii ale inteligenei artificiale n procesele de afaceri i astfel au aprut sistemele expert pentru afaceri (Business Expert System BES). Astzi, sistemele expert joac rolul de consultani n problemele de natur economic a oricrei firme. Ultimul deceniu al mileniului este caracterizat de dezvoltarea sistemelor informatice strategice (Strategic Information System SIS). Acestea joac un rol direct n obinerea avantajului competitiv al unei firme. Modelul lui Michael Porter a stat la baza crerii a numeroase astfel de sisteme informatice strategice. Firmele de astzi trebuie s se bazeze pe tehnologia informaiei pentru a fi competitive pe piee puternic concureniale. n cadrul unei firme se pot ntlni ase tipuri de sisteme informatice structurate pe 4 nivele: 1. Nivelul strategic acestui nivel i corespunde sistemul informatic executiv, EIS. 2. Nivelul tactic la acest nivel se regsesc sistemul suport al deciziilor, DSS, i sistemul informatic managerial, MIS.
3. Nivelul de cunotine sistemul bazat pe cunotine, Knowledge Based System KBS. 4. Nivelul operaional se regsesc sistemul de automatizare a activitilor din birouri (Office Automation System OAS) i sistemul de procesare a tranzaciilor (Transaction Processing System TPS).
3.2. Sisteme integrate pentru firme

Schimbrile tot mai rapide n mediul de afaceri i cresterea complexitii activitilor din cadrul unei firme necesit o adaptare permanent, ntr-un ritm alert, care adeseori pune la ncercare capacitile de efort i analiz ale factorului uman. Sistemele / aplicaiile integrate au fost create ca soluii la aceste provocri, fiind capabile s proceseze volume mari de date i informaii agregate n scopul optimizrii i eficientizrii proceselor. Un sistem integrat de aplicaii pentru ntreprinderi este o soluie software complex, de nivel nalt, multi-modular, ale crei elemente sunt integrate ntr-o platform comun, care ofer suport pentru gestiunea resurselor i coordonarea diferitelor procese dintr-o firm n vederea realizrii obiectivelor de afaceri. Soluia caut s modernizeze, s integreze procesele economice, s sincronizeze funciile ntreprinderii i s coordoneze alocarea resurselor. De asemenea, virtual, permite extinderea firmei dincolo de limitele sale fizice: spre furnizori, clieni i parteneri. n practic aceste sisteme de aplicaii se regsesc sub diferite denumiri: ERP, SCM, CRM, PLM, BI etc. n continuare sunt descrise o serie de tipuri mai importante de aplicaii:
ERP (Enterprise Resource Planninng) - n sens restrns se refer la aplicaiile pentru planificarea
i urmrirea proceselor de producie, cu luarea n considerare a materialelor, proceselor tehnologice i resurselor (maini, utilaje) disponibile. Actualmente, noiunea de ERP este adesea utilizat n sens larg, pentru a desemna sistemele integrate pentru ntreprinderi. n acest sens, un sistem ERP poate include ca module celelalte tipuri de aplicaii menionate. SCM (Supply Chain Management) - se refer la gestiunea lanului de aprovizionare din punct de vedere al planificrii cantitilor de produse transferate i stocate ntre "verigile" unui astfel de lan - furnizori de materii prime, productori, distribuitori i clieni. Se urmresc astfel optimizri pentru ntregul lan, n locul optimizrilor locale ale fiecrei ntreprinderi. Funcionarea unui astfel de lan de aprovizionare presupune relaii de parteneriat ntre ntreprinderi, care s faciliteze integrarea soluiilor software ale acestora, exemplul tipic fiind industria construciei de automobile. CRM (Customer Relations Management) sunt aplicaii care sprijin implementarea unei strategii de orientare spre client, prin gestiunea unitar a tuturor proceselor ce presupun interaciunea cu clientul: vnzari, servicii de garanie i post-garanie (callcenter / support) etc. Pot fi incluse i procese analitice, precum analiza portofoliului de clieni i a comportamentului acestora, crearea campaniilor de marketing pe anumite grupuri int etc. BI (Business Intelligence) sunt aplicaii destinate proceselor de decizie de nivel nalt ale ntreprinderii. Aplicaiile de acest tip realizeaz colectarea i agregarea datelor tranzacionale (referitoare la derularea proceselor ntreprinderii), pe baza unui sistem de indicatori de performan. Bazate pe tehnologii de tip Data Warehouse/OLAP, aceste aplicatii permit analize detaliate ale datelor pentru identificarea tendinelor de evoluie i a cauzelor acestora. Prin instrumente vizuale panou de bord, se pot urmari performantele ntreprinderii, cuantificate prin indicatorii de performan, fiind indicate i abaterile acestora de la valorile planificate. PLM (Product Lifecycle Management) se refer la procesele de gestiune a ciclului de via al produselor i serviciilor, trecnd prin etapele de concepie, proiectare, producie, service i retragere. Prin gestiunea unitar a datelor despre produse se urmrete accelerarea lansrii produselor (time-to-market), mbuntairea calitii i scderea costurilor.
3.2.1. Enterprise Resource Planning Scopul sistemelor ERP Sistemul de gestiune integrat a proceselor de afaceri are drept scop integrarea i ordonarea informaiei, realizarea unei mai bune comunicri de date/informaii n firm, prin fluidizarea schimbului de date ntre departamente, mbuntirea cooperrii i interaciunii dintre diverse compartimente i asistarea procesului de management de nivel superior. Functionalitile unui ERP Modulele unui ERP acoper mai multe domenii de interes ale unei afaceri: Financiar-contabil. Mijloace fixe. Planificarea produciei. Gestiunea stocurilor. Gestiunea achiziiilor. Gestiunea relaiilor cu clienii. Gestiunea resurselor umane. Managementul calitii. Managementul proiectelor. Managementul lanurilor de aprovizionare. Managementul ciclului de via al produselor. Analiz i suport decizional. Caracteristicile unui ERP Fiind o soluie software integrat, un sistem ERP trebuie s aib cteva caracteristici cheie: Adaptabilitate - Funcionalitatea standard a aplicaiilor poate fi modificat conform cerinelor specifice ale ntreprinderii utilizatoare, de regul n procesul de implementare a unui ERP. Realizarea adaptrilor este posibil prin configurare (parametrizare, setare, customizing) care presupune modificarea unor structuri de date sau parametri de sistem; modificri mai importante pot necesita modificarea / dezvoltarea codului aplicaiei. n al doilea caz apare dezavantajul ca procesul de actualizare (update) devine mai complicat, deoarece modificrile de cod trebuiesc refacute dup aplicarea pachetelor de actualizare ale producatorului. Generalitate s poat cuprinde i s satisfac cele mai multe tipuri de organizaii, s suporte mai multe funcii organizaionale; generalitatea i puterea de a sustine organizaii mari i complexe coexista cu flexibilitatea specifica organizaiilor mici. Funcionalitatea general se refer la informaizarea proceselor aplicabile oricrei organizaii, de ex. contabilitate, resurse umane, aprovizionare etc. Oferta de aplicaii de ntreprindere cuprinde i soluii specifice anumitor domenii de activitate, cum ar fi sntate, telecomunicaii, comer cu amnuntul (retail), industrie aeronautic, administraie public etc. Modularitate - s aib o structur modular i orice modul s poat fi inclus sau detaat de cte ori este nevoie fr a afecta celelalte module sau ntreaga structur; toate modulele sistemului sunt strns legate ntre ele toi utilizatorii lucrnd simultan asupra acelorai date, prin reeaua de calculatoare, n funcie de atribuiile pe care le au. Sistem deschis - s aib o arhitectura de sistem deschis, s ofere facilitate care s permit integrarea cu alte aplicaii deja existente i/sau tranziia cu eforturi i costuri minime de la alte module ale aplicaiei; s ofere un mediu de dezvoltare i documentare pentru utilizatori avansai care preiau pri din ntreinerea, adaptarea, extinderea sistemului, dar i integrarea cu platforme i tehnologii de ultim or cum sunt Web/Intranet/Internet/Data Warehouse. Interfa cu utilizatorul standardizat - Modul de operare este unitar, prin standardizarea design-ului formularelor, a meniurilor aplicaiilor i a regulilor de operare. n acest mod este facilitat procesul de nvare pentru utilizatori.
Securitatea datelor - s permit accesul la date n condiii de securitate deosebite numai n conformitate cu drepturile acordate fiecrui utilizator; siguran i securitatea datelor sunt asigurate la un nivel deosebit prin sistemul de drepturi de acces. Conectivitate - s nu fie limitat la graniele organizaionale ale companiei ci s suporte conectiviti cu alte module de afaceri din alte companii. Simularea realitatii s permit simularea proceselor de afaceri reale i s poat atribui responsabiliti utilizatorilor care controleaz sistemul. Pe lng aceste caracteristici generale trebuie remarcat faptul c un ERP trebuie s aib o colecie a celor mai bune procese de afaceri i practici de afaceri, pe care s le ofere utilizatorilor. Avantaje i limite ale utilizarii sistemelor ERP Avantaje: asigur informaii on-line i n timp real pentru toate ariile funcionale ale unei companii; informaia este introdus n sistem o singur dat ntr-o singur baz de date ceea ce asigur acurateea i standardizarea datelor i elimin redundanele; mbuntete accesul la date n vederea lurii deciziilor n timp util pentru a susine deciziile de afaceri; diminuarea timpilor de rspuns ctre client dar i la operaiile de afaceri realizate - furnizeaz instrumente de raportare managerial divesificate ceea ce mbuntete controlul proceselor de afaceri de ctre conducerea companiei; mbuntete procesele de afaceri deoarece oblig la utilizarea celor mai bune practici ce sunt incluse n aplicaii; faciliteaz companiilor mari s acopere toate domeniile funcionale; asist activitile cele mai importante din companie i constituie, din acest motiv, o soluie din cele mai bune pentru management; conduce la integrarea complet a aplicaiilor nu numai ntre departamentele unei companii ci i ntre mai multe companii; elimin cele mai multe probleme ale unei afaceri: criza materiilor prime, sporirea producivitii, livrarea prompt, calitatea produselor etc.; reduce golurile de informaii din organizaie i ofer un flux al informaiilor sigur i fr redundante faciliteaz introducerea celor mai noi tehnologii (Internet, Intranet, Videoconferine, E-Commerce, EFT - Electronic Fund Transfer, EDI - Electronic Data Interchange etc.); ofer o perspective global asupra a ceea ce se ntmpl n cadrul structurii organizaionale, asupra cerinelor actuale ale companiei dar i oportuniti pentru mbuntirea continu i rafinarea proceselor de afaceri; asigur companiei avantaje competiionale i mbuntete imaginea companiei; mbuntete serviciile ctre clieni i prin aceasta se mbuntete imagine companiei. Limite ale utilizarii ERP: durata relativ mare a implementrii; costurile implementrii: cheltuiala pentru achiziionare, costuri suplimentare/ascunse (instruire, inegrare, testare, ntreinere, adaptare, conversia datelor din sisteme vechi, consultan); amplificarea problemelor de securitate. 3.2.2. Supply Chain Management n anii 1990 civa autori au ncercat s pun esena SCM ntr-o singur definiie. Ea conine: obiectivele teoriei de management; grupul int; obiectiv-ul (ele); mijloacele pentru atingerea obiectivelor.
Obiectivul SCM este n mod evident suplly chaine, care reprezint o reea de organizaii ce sunt implicate prin legturi amonte i aval, n diferite procese i activiti care produc valori sub forma produselor i serviciilor ce ajung la consumatorii finali. ntr-un sens mai larg un SCM const din dou sau mai multe organizaii separate legal, dar unite prin fluxuri de materiale, financiare i informaii. Aceste organizaii pot fi firme ce produc pri componente i produse finite, firme ce asigur logistica i chiar clientul final nsui. O reea uzual nu se concentreaz numai pe fluxurile dintr-un singur lan, ci exist fluxuri de lucru divergente i convergente ntr-o reea complex ce rezult din mai multe ordine date de diferi clieni care trebuie realizate (deservite) n paralel. Pentru a uura complexitatea o organizaie dat se poate concentra numai pe o parte din SCM general. Ca un exemplu privind n aval imaginea unei organizaii poate fi limitat de clienii clienilor ei, iar n amonte de furnizorii furnizorilor ei. ntr-un sens restrns termenul de SCM este de asemenea aplicat unei companii mari care are cteva sedii adesea localizate n ri diferite. Coordonarea fluxurilor de materiale, informaii i financiare ntro astfel de companie multinaional ntr-un mod eficient rmne o sarcin formidabil. Oricum luarea deciziilor trebuie s fie uoar, deoarece aceste puncte fac parte dintr-o singur organizaie mare cu un singur nivel de management. Un SCM n acest sens este numit i SCM interorganizaional, n timp ce termenul intraorganizaional se refer la SCM. n sens restrns, fr a ine seama de aceste diferene ntre diferite uniti funcionale ca marketing, producie, aprovizionare, logistic i finane este necesar o strns colaborare, acesta fiind condiia esenial i fireasc n firmele de astzi. Obiectivul care guverneaz toate eforturile ntr-un SCM este creterea competitivitii. Aceasta deoarece n ochii consumatorului final nu este responsabil o singur unitate organizatoric pentru competivitatea produselor i serviciilor ei, ci SCM ca un ntreg. Deci competitivitatea a fost luat i ridicat de la o singur companie la un SCM. Evident convingerea unei companiei individual s devin parte dintr-un SCM necesit o situaie de succes pentru fiecare participant, la un drum lung de curs lung, n timp ce aceasta nu se poate implica pentru toate prile ntr-o curs scurt. Un impediment general acceptat n mbuntirea complexitii este asigurarea unui service superior clienilor. Ca alternativ o firm poate s-i cresc competivitatea prin asigurarea unui service general, acceptat la un cost minim. Sunt dou cii principale de mbuntire: una este o mai apropiat integrare a organizaiilor i nchiderea integral a organizaiilor insolvabile, a doua este o mai bun coordonare a fluxurilor materiale, informaionale i financiare. Depind barierele organizaionale, alinierea strategiilor i gestionarea lanului de aprovizionare sunt subiecte comune n acest sens. Se va defini termenul de management al lanului de aprovizionare ca fiind sarcina de a integra unitile organizaionale de-a lungul unui lan de aprovizionare, de a coordona materialele, informaiile i fluxurile financiare pentru a acoperi cererile clientului, cu scopul de a mbunti competitivitatea lanului de aprovizionare ca un tot. 3.2.3. Customer Relationship Management CRM-ul este un proces care ajut la o mai bun nelegere a nevoilor i comportamentului clienilor. El ajut la dezvoltarea i la trasarea strategiilor de afaceri pentru client i de asemenea abordeaz problemele prin implementarea lor. n termeni simpli utilizarea eficient a unui CRM ajut clientul i organizaia acestuia s ndeplineasc acele eluri mult dorite, acele inte referitoare la potenialele performane, achiziii, creterea i pstrarea afacerii. O baz de date centralizat furnizeaz informaiile despre clieni i asigur coordonarea echipelor de marketing, vnzri i suport.
Un sistem eficient de CRM are drept scop gestionarea i optimizarea ciclului de via al clientului dar i construirea unei nelegeri corespunztoare sau a unei legturi ntre diverse departamente, fore de vnzri i clieni n cadrul unor companii mari, care n final toate la un loc vor spori producia companiei. CRM (Managementul Relaiei cu Clienii) este o strategie comercial care urmrete stabilirea unei relaii profitabile i de lung durat cu clienii. Astzi, CRM este introdus n majoritatea companiilor mari. Managementul informaiei este susinut i cunotinele companiei sunt pstrate. Prin folosirea CRM-ului, o organizaie poate folosi nregistrrile anterioare ale potenialilor clieni i cumprtori precum i tendinele anterioare de achizitie, tendine care le-au preferat mai devreme dar i nevoile acestora, pentru a crea un centru al clienilor i un sistem de marketing central referitor la nevoile clienilor. Companiile care utilizeaz sisteme CRM se pot atepta imediat: la pstrarea i obinerea mai multor clieni, n consecin la o cretere global; la creterea i maximizarea absolut a ciclurilor de via a clienilor; la mbuntirea serviciilor pentru clieni prin personalizarea acestora; Succesul unei aplicaii CRM const n continua dezvoltare a acestuia, pentru a satisface noile nevoi i cerine ale utilizatorilor acestuia. Este foarte important ca utilizatorul de CRM s nteleag c succesul unei astfel de aplicaii const n continua dezvoltare i modelare a funciilor aplicaiei dup nevoile sale. 3.2.4. Business Intelligence Luarea deciziilor bune n afacerile care sunt fcute este la fel de important ca i n viaa particular. n fiecare zi trebuie s se ia decizii care s determine direcia i eficiena activitilor dintr-o organizaie. Se iau decizii n legatur cu producia, marketingul, personalul etc. Deciziile luate afecteaz costurile, vnzrile, profitul etc. Ca i n viaa personal, cheia pentru succesul organizaiei este n modul n care se ia deciziilor. Organizaiile trebuie s ia decizii eficiente. Cine ia deciziile? La prima vedere, se poate spune ca doar persoanele din varful ierarhiei (CEO, director, preedinte) trebuie s ia decizii eficiente care s aduc succesul n organizaie. Planurile eficiente dezvoltate de conducerea organizaiei pot eua datorit deciziilor greite luate de ctre persoane din prile inferioare ale ierarhiei n procesul de implementare sau n cel de executie. n concluzie, decizii eficiente trebuie luate de toi cei din organizaie. Deciziile eficiente luate la fiecare nivel al organizaiei duc ctre succes. Ce sunt deciziile eficiente? Deciziile eficiente sunt acele alegeri care duc organizaia mai aproape de obiectivele stabilite n timp util. Dac se ia n consideraie definiia de mai sus se poate observa trei componente importante care ajut personalul de decizie din cadrul organizaiei s ia decizii eficiente: stabilirea obiectivelor; stabilirea unor mrimi de msurat pentru stabilirea abaterii de la obiective; stabilirea termenelor n care trebuie atinse obiectivele. Aceste informaii reprezint baza de plecare pentru luarea deciziilor, dar i o metoda de evaluare a calitaii deciziilor luate. Obiectivele trebuie s fie stabilite clar i fcute cunoscute tuturor celor implicai n activitatea organizaiei. Pentru ca un obiectiv s poat sta la baza unei decizii eficiente trebuie s defineasc i o metod de msurare pentru stabilirea n orice moment a abaterii nregistrate n activitatea curent.
Odat stabilite obiectivele clare, metodele de msurare ale acestor obiective i metodele de evaluare, se pune ntrebarea: Cum poate o organizaie s obin i s distribuie informaiile necesare pentru luarea deciziilor i evaluarea eficienei acestora? Rspunsul la aceast ntrebare este: Prin soluii de Business Intelligence. Putem defini Business Intelligence drept platform de prezentare a informaiilor ntr-un mod corect, util i specific ctre fiecare persoan de decizie n timp util pentru a putea servi n luare deciziilor eficiente. Business Intelligence nu reprezint un set de rapoarte tiprite sau prezentate pe ecran. Rndurile unui raport de vnzri, spre exemplu, pot conine informaii detaliate i exacte, dar nu reprezint o soluie de Business Intelligence pn cnd nu sunt puse ntr-un format care poate fi uor neles i interpretat de ctre o persoan de decizie n vederea stabilirii unei soluii eficiente pentru o situaie particular ntlnit n activitatea curent.
3.3. Sistemul informatic de gestiune

Sistemul informatic de gestiune este sistemul informatic folosit pentru administrarea i
controlul resurselor unui sistem economic, deoarece termenul de gestiune are semnificaia, pe de o parte, de administrare a bunurilor unei ntreprinderi i, pe de alt parte, de rspundere a pstrrii bunurilor i amnuirii fondurilor unei ntreprinderi ale crei bunuri sunt reprezentate de resursele necesare pentru realizarea obiectivelor sale, denumit generic sistem economic. [Andronie, 2007] Administrarea i controlul resurselor unui sistem economic impun administrarea i controlul activitilor pe care le desfoar sistemul economic respectiv pentru ndeplinirea obiectivelor sale.
Capitolul 4 Metodologii de realizare a sistemelor informatice

Procedeele pentru definirea, organizarea practic i etapizarea activitilor analizei de sistem constituie aa numitele metodologii pentru analiza i proiectarea sistemelor i reprezint obiectul preocuprii unui numr mare de specialiti din ntreaga lume. Metodele i conceptele fundamentale de realizare a sistemelor informatice pentru un organism oarecare au la baz termenii de metod i metodologie asociai direct domeniului respectiv. Aceti termeni vor fi actualizai n raport cu specificul domeniului analizat, evoluia cadrului legislativ, dinamica activitii de informatic i tendinele fundamentale de evoluie a sistemului analizat. Pentru realizarea sistemelor informatice se utilizeaz urmtoarele concepte:
Metoda: reprezint modul unitar sau maniera comun n care analitii de sistem, programatorii i alte categorii de persoane implicate, realizeaz procesul de analiz a sistemului informaional decizional, proiectarea i introducerea sistemului informatic; sau reprezint totalitatea conceptelor, modelelor, nivelelor, etapelor i tehnicilor specifice de formalizare necesare pentru definiiile, listele, comunicaiile, datele i prelucrrile specifice unui sistem informatic. Metodologia: este reprezentat de setul finit particular definitoriu al unei metode prin intermediul unui sistem coerent de formulare i/sau procese informatice necesare pentru modelarea i formalizarea total a unui sistem informatic. Tehnici de lucru: reprezint felul n care se acioneaz eficient i rapid, n cadrul unei metode, pentru soluionarea diferitelor probleme ce apar n procesul de proiectare. Instrumentele: utilizate n proiectarea sistemului informatic, sunt acele mijloace care se utilizeaz de ctre echip pentru realizarea scopului propus, ele depind de metodele i tehnicile utilizate, precum i de procedurile analizate i proiectate. Procedee de lucru (procedur): succesiunea operaiilor necesare parcurgerii unor etape ale aciunii i aplicrii unor tehnici n cadrul metodelor n conformitate cu o rutin de lucru dat.
Este bine cunoscut faptul c preocuprile pentru analiza i proiectarea sistemelor informatice au aprut ca rezultat al aplicrii unora dintre ideile analizei sistemice n tehnica folosirii echipamentelor moderne de culegere, prelucrare i stocare a informaiei. De aici decurge faptul ca metodologiile de analiz i proiectare a sistemelor informatice trebuie s fie axate n primul rnd pe utilizarea eficient a calculatoarelor electronice, pe valorificarea posibilitilor i facilitilor pe care le ofer acestea proiectanilor de sisteme i n final utilizatorilor. Pe de alt parte, metodologiile de analiz i proiectare a sistemelor informatice tind s integreze calculatorul n nsui procesul de analiz. Sintetiznd cele prezentate, se poate aprecia c: O prim caracteristic a metodologiilor de analiz i proiectare a sistemelor informatice este orientarea spre soluii care prevd organizarea centralizat a informaiei n unitile care fac obiectul analizei. O a doua caracteristic a metodologiilor de analiz i proiectare a sistemelor informatice deriv din posibilitile remarcabile de prelucrare rapid a informaiilor pe care le ofer calculatoarele. Metodologiile de analiz i proiectare a sistemelor informatice sunt numeroase iar alegerea uneia sau alteia n cadrul proiectrii unui sistem informatic este o opiune destul de grea i care, de obicei, ine cont de pregtirea specialistului n utilizarea i cunoaterea ct mai multor metode.
Metodologii de realizare a sistemelor informatice 3737
n funcie de modul de abordare i domeniul de aplicabilitate, metodologiile utilizate sunt: [Lungu1&alt, 1995] 1. Din domeniul gestiunii: AXIAL, al firmei IBM; MERISE, Ministerul Industriei din Frana; IE, James Martin; DA, Universitatea Michigam; SSADM, Marea Britanie. 2. Orientate obiect, se bazeaz n formalizarea sistemelor pe noiunea de obiect (entitate pentru date i aciune pentru procese): OMT, General Electric SUA; OOD, SUA; ISD, Michael Jackson. 3. Pentru conducerea proiectelor de sisteme informatice, se utilizeaz pentru elaborarea sistemelor ntr-o concepie tiinific: SDM/S; METHOD/1; NAVIGATOR (Ernest /Zoung James Martin). O alt clasificare a metodologiilor de realizare a sistemelor informatice, care este cu precdere utilizat n prezent este: 1. Metodologii cadru, cu scop orientativ general. 2. Metodologii proprii unor firme productoare de echipamente de calcul sau sisteme informatice. Metodologiile de realizare a sistemelor informatice cuprind: 1. Modalitatea de abordare a sistemelor. 2. Regulile de formalizare a datelor i a proceselor de prelucrare. 3. Instrumente pentru concepia, realizarea i elaborarea documentaiei. 4. Modalitatea de derulare a proiectului i aciunile specifice fiecrei etape (ciclul de via). 5. Definirea modului de lucru. 6. Modaliti de administrare a proiectului. Tendinele actuale n evoluia metodologiilor de proiectare sunt: 1. nlturarea monopolul deinut de-a lungul unei perioade de timp de anumite metodologii, precum MERISE n Frana i SSADM n Marea Britanie. 2. mbogirea reciproc a metodologiilor existente. 3. Asimilarea tendinelor fireti de evoluie a informaticii (arhitectura client/server, abordarea pe obiecte, modelul relaional pentru date). 4. Tendina spre standardizare: modelul entitate-relaie pentru date; diagrama de flux pentru aspectele funcionale; modele de prelucrare i de comunicaie pentru aspectele dinamice. 5. Integrarea metodologiilor existente, a limbajelor de modelare i a instrumentelor n cadrul unor procese de dezvoltarea software care permit modelarea mai flexibil a sistemului. Pe parcursul timpului aceste metode, mijloace i tehnici specifice analizei de sistem au evoluat n mod considerabil, i ar fi imposibil ca s se poat surprinde toate aceste metode care au existat i care exist n momentul de fa. Din acest motiv se vor enumera cele mai importante dintre metodologiile existente, i se va insista pe una din metodologiile de dat recent, metodologia UML.
4.1. Etape n proiectarea unui sistem informatic

Realizarea unui sistem informatic implic mai multe etape teoretice. Acestea pot fi sistematizate astfel: stabilirea cerinelor utilizatorului; analiza i specificarea produsului; proiectarea general i de detaliu; implementarea codului; testarea produsului; instalarea i mentenana produsului. n practic, majoritatea analitilor de sistem au tendina de a parcurge doar anumite etape, dac nu chiar una singur, i anume aceea de scriere de cod. n general acest lucru este explicat prin lipsa de
timp i n cele mai multe cazuri, de incapacitatea beneficiarului de a stabili i formula nc de la nceput corect cerinele produsului software. Este ns adevrat c nu orice produs software trebuie s parcurg toate etapele teoretice enumerate. Dar tot att de adevrat este i faptul c, parcurgerea acestor etape, poate duce la rezultate superioare i la eliminarea unor erori de proiectare i programare nc din fazele iniiale ale proiectului. Ceea ce este mai duntor este faptul c de obicei se renun la etapele de analiz i proiectare ale produsului, care sunt etape cheie n dezvoltarea aplicaiei, ele furniznd o schematizare i o vedere de ansamblu, care duc la o nelegere mai profund a problemei abordate. Proiectarea unei aplicaii software complexe, de dimensiuni mari, dezvoltat n cadrul unei echipe de software, nu se face trecnd direct la implementarea programului, ci trebuie s urmeze etapele enumerate mai sus. Dup cum se observ, proiectarea nu se termin odat cu implementarea, pentru c sistemul creat trebuie testat i apoi instalat. Dup instalarea produsului software acesta trebuie ntreinut, operaie care trebuie realizat continuu. Ceea ce s-a descris mai sus constituie unul din cele trei cicluri ale metodologiilor utilizate n analiza i proiectarea sistemului, i anume ciclul de via al unui sistem informatic o metodologie comun de dezvoltare a sistemelor, caracterizat prin mai multe faze care marcheaz evoluia eforturilor de analiz i proiectare a sistemelor (Hoffer), i care constituie obiectul de studiu al ingineriei programrii (este un domeniu care ncearc o abordare sistematic a dezvoltrii, operrii, ntreinerii i retragerii unui program de pe pia). n general n cadrul metodologiilor se pot distinge trei cicluri majore: Ciclul de via al unui sistem (recursivitate). Ciclul de abstractizare (sau ciclul de modelare, raionamentul). Ciclul de decizie (sau de validare, conducere). Din punct de vedere al unei metodologii utilizate, sistemele informatice au un ciclu de via propriu, care ncepe cu decizia de realizare a sistemului informatic, cuprinde faza de elaborare, faza de utilizare i faza de perfecionare i se ncheie cu decizia de abandonare a sa n forma existent i nlocuirea lui cu un nou sistem. Numrul acestor etape variaz de la trei (analiz, proiectare, implementare) la peste douzeci. Odat cu apariia abordrii orientate obiect etapele s-au diversificat. Totodat, dup apariia tehnicilor de dezvoltare rapid a aplicaiilor (mediile RAD Rapid Application Development), numrul etapelor s-a redus din nou. Cu toate acestea, fiecare metod realizeaz dezvoltarea unui sistem ntr-o succesiune de etape, sau faze, care difer de la un model la altul. Ceea ce este important de reinut este faptul c indiferent de ce subsistem se dorete a fi implementat, n realizarea acestuia se utilizeaz o anumit metod. Cu toate acestea majoritatea modelelor prezint anumite etape tipice, care sunt: 1. Studiul i analiza sistemului existent. Aceast activitate include stabilirea caracteristicilor generale, tehnico economice, ale unitii analizate, cu precdere a funciei de baz, precum i studiul sistemului informaional pentru conducere existent, ceea ce nseamn identificarea caracteristicilor acestui sistem, a fluxului informaional i a metodelor i mijloacelor tehnice de prelucrare a datelor. 2. Conceperea sistemului informatic, obiectul acestei etape l constituie elaborarea proiectului de ansamblu al sistemului informatic, pe baza cerinelor i restriciilor formulate n prima etap. 3. Proiectarea de detaliu: obiectivul principal l reprezint elaborarea componentelor funcionale detaliate ale sistemului i a specificaiilor de definire a produselor program, n scopul acceptrii lor de ctre beneficiar i ntocmirii suportului documentaiei de prezentare, utilizare i exploatare.
4. Elaborarea programelor. Aceast etap este consacrat elaborrii produselor program i procedurilor manuale aferente componentelor sistemului informatic, precum i testrii componentelor. 5. Implementare sistemului, obiectivul principal al acestei etape este lansarea n exploatare curent a sistemului. 6. Exploatarea, ntreinerea i dezvoltarea sistemului informatic. Fiecare din aceste etape au la rndul lor mai multe activiti specifice. Astfel etapa de studiul i analiza sistemului existent conine urmtoarele activiti: studiul sistemului existent; evaluarea sistemului existent; evaluarea gradului de pregtire a unitii economice; formularea cerinelor i a restriciilor pentru realizarea sistemului informatic. Conform raportului Euromethod etapele care trebuie parcurse n dezvoltarea sistemelor informatice sunt:
Planificarea strategic cuprinde informaii referitoare la organizaia pentru care se elaboreaz
sistemul informatic, ct i la sistemul nsui. Studiul de fezabilitate are rolul de a asigura informaiile obiective necesare pentru a stabili dac un proiect poate fi demarat sau nu. Dimensiunile i durata studiilor de fezabilitate variaz n funcie de mrimea i de natura sistemului de implementat. Definirea cerinelor variaz n funcie de metoda utilizat. n general, funciile acestei etape sunt: nelegerea scopului i funciile sistemului, specificarea funciilor din perspectiva utilizatorului. Proiectarea cuprinde la rndul su proiectarea logic i proiectarea tehnic. Codificarea reprezint activitatea de transformare a algoritmilor definii n etapa de proiectare ntr-un limbaj de programare. Implementarea este etapa n care are loc procesul de instalare a echipamentelor i a sistemului informatic (software-ului) n vederea finalizrii sistemului i drii lui n funciune. ntreinerea i dezvoltarea se refer la ntreinerea sistemului elaborat.
4.2. Modele utilizate n proiectarea unui sistem informatic

n prezent exist mai multe modele de realizare a sistemelor informatice (numite modele ale ciclului de via ale dezvoltrii sistemului), printre care pot fi menionate:
Modelul liniar (n cascad, sau Waterfall) este cel mai vechi i cel mai cunoscut model. A fost dezvoltat n perioada anilor 1960 (a fost lansat la nceputul anilor 1970 de ctre W.W. Royce), caracteristica principal constnd n parcurgerea succesiv a unor etape, numite faze, fiecare faz constituie o trecere de la un nivel de abstractizare ridicat la un nivel mai sczut de abstractizare. Printre dezavantajele cele mai importante sunt urmtoarele: dac s-a produs o eroare este foarte greu de revenit la faza la care s-a produs eroarea; metoda a fost dezvoltat ntro perioad cnd sistemele dominante erau cele de dimensiuni mici i cu o arhitectur compact; nu se preteaz la transpunerea s pe calculator. Fazele, la rndul lor, sunt structurate pe activiti i subactiviti. Trecerea la faza urmtoare se realizeaz dup parcurgerea n ntregime a fazei precedente. Modelul este folosit de Booch n fazele de proiectare i implementare din cadrul metodei OOADA (Object-Oriented Analysis and Design with Application) i Ivar Jacobson pentru toate etapele metodei OOSE (Object-Oriented Software Engineering). Ideea de baz a modelului este regsit i n alte modele, cum ar fi: modelul V, modelul incremental, i modelul fntnei arteziene.
Modelul incremental (rapid-prototyping) a fost creat pentru a acoperi deficienele modelului
liniar; diferena principal ntre aceste modele const n introducerea conceptului de dezvoltare incremental. Conceptul de dezvoltare incremental se refer la crearea unor mici salturi de la vechea variant de sistem la noua variant care conine un plus de funcii. Modelul de concepie n V: pentru evidenierea faptului c anumite faze ale ciclului de via sunt condiionate de faze anterioare s-a propus reprezentarea ciclului de via al unui sistem informatic ca un ciclu de concepie n V. Acest tip de model a fost lansat n 1990 de Ould. Un mare dezavantaj al acestei metode este acela c nu se poate valida analiza fcut la nceputul proiectului dect atunci cnd toate activitile de programare, testare i integrare sunt terminate. Modelul operaional realizeaz specificaii executabile, mrete rolul automatizrii i stabilete o strns legtur ntre specificaii i implementare etc. Atunci cnd se ncepe dezvoltarea unui sistem se poate alege unul din modelele prezentate, sau altele existente. Problema cu cele mai multe metode este c ele au att reguli implicite ct i explicite. Regulile explicite sunt prezentate de obicei n documentaia de realizare, iar cele implicite nu sunt prezentate nicieri. Alegerea modelului depinde de mrimea sistemelor de analizat i dezvoltat, precum i de domeniile crora le aparin. O alt latur care trebuie avut n vedere atunci cnd se alege o metod sau alta este modalitatea de abordare a sistemului: n ntregime sau pe pri componente. Un alt aspect, dar nu neaprat ultimul, care trebuie abordat este informaizarea metodei de proiectare. Informaizarea reprezint un suport pentru o metod i este o parte integrat n procesul de dezvoltare a sistemului informatic.
4.3. Metodologii de analiz i proiectare a sistemelor informatice

Metodologiile de analiz i proiectare a sistemelor informatice au aprut ca o necesitate de definire a unor pai i reguli generale, ce trebuie ndeplinite pentru analiza, proiectarea i implementarea diferitelor tipuri de probleme. Pentru a nu descoperi de fiecare dat procedeul care a dus la succesul realizrii unui produs anterior, s-a cutat definirea unor metode pragmatice de structurate i ulterior de analiz i proiectare a acestora. Reutilizarea este un cuvnt cheie n dezvoltarea aplicaiilor din ultimii ani, iar acesta nu se refer numai la reutilizarea prilor de cod, ci la toat experiena acumulat pe parcursul dezvoltrii produsului software. Un factor important care a dus la apariia conceptului de reutilizare, n special n ingineria programrii, este timpul, termenele realizrii proiectelor devenind tot mai scurte. Astfel produsul este dezvoltat din mers, n sensul c programatorul ncearc s ghiceasc i s implementeze cerinele schematice ale clientului. Acesta urmeaz s formuleze cerinele efective pornind de la prototipul furnizat de programator. ntrebarea fireasc este de ce nu exist o singur metodologie care s fie general valabil i aplicabil n toate cazurile ? Un rspuns posibil este acela c metodologiile difer ntre ele destul de mult, fiind mai eficiente n anumite domenii sau cazuri. Ele au luat natere din generalizarea soluiilor oferite pe cazuri particulare. 4.3.1. Metodologii de analiz sistemic inndu-se cont de complexitatea celor mai multe sisteme existente n natur studierea sistemelor se face ntr-o manier aparte numit abordare sistemic. Spre deosebire de abordarea cartezian, care
const n a separa i a izola fiecare subproblem pentru o prelucrare ulterioar, abordarea sistemic propune o viziune unic i global a problemei de rezolvat. O idee important care caracterizeaz analiza sistemic, i implicit a sistemelor informatice, este posibilitatea perfecionrii sistemelor printr-o activitate de analiz i proiectare tiinific a acestora. O alt idee fundamental, specific analizei de sistem este caracterul su multidisciplinar. Organizarea acestor activiti multidisciplinare constituie o alt idee de baz a analizei de sistem i poate cea mai important dintre toate. O problem decisiv este alegerea metodei ce urmeaz a fi aplicat pentru fiecare caz n parte. Se poate afirma c, acesta este pasul cel mai important n desfurarea proiectului. Dac alegerea fcut este corect, acest fapt va duce la rezultate pozitive din toate punctele de vedere. n cazul n care s-a optat ns pentru o metod nepotrivit problemei de rezolvat, rezultatele proiectului vor fi pe msur (din aceast cauz sunt situaii cnd la sfritul proiectului se constat c aplicaia trebuie reproiectat i implementat ntr-un mod diferit). Alegerea aplicrii metodei pentru rezolvarea unei anumite probleme depinde de mai muli factori, printre care amintim: tipul problemei de rezolvat; domeniul n care se ncadreaz problema; pregtirea i calificarea echipei de dezvoltare a produsului software; resursele hardware i software disponibile; bugetul i timpul alocat proiectului. n legtur cu evoluia i progresele din ultimii ani n analiza de sistem, se poate descifra dou principale tendine de aplicare ale acestei metodologii: un sens restrns, n acest sens analiza se orienteaz n special spre aspecte legate de culegerea, transmiterea, prelucrarea i stocarea informaiilor ntr-un sistem fr a se aprofunda procedeele tiinifice de rezolvare a problemelor decizionale aferente muncii de conducere din sistemul supus analizei. n general aceast variant se numete analiza i proiectarea sistemelor informaionale, iar metodologiile sunt de tip informaional. un sens mai larg, n care se include, pe lng preocuprile enumerate mai sus, i pe cele care vizeaz metodele de optimizare a problemelor de decizie. Aceast variant este denumit analiza i proiectarea sistemelor informaional-decizionale., iar metodologiile sunt de tip informaionaldecizional. Metodologii de tip informaional Printre tehnicile de analiz sistemic din aa numit generaia a II-a, o mare utilizare au cunoscut-o grilele de analiz informaional neautomatizat, a cror sarcin era de a stabili informaiile de intrare n sistem necesare pentru obinerea anumitor documente de ieire. Printre primele metode de analiz informaional cu ajutorul grilei temporale automatizate, un instrument metodologic auxiliar al analistului, care au stabilit relaia ntre intrri i ieiri a fost metoda T.A.G. (Time Automated Grid) - grila automatizat de analiz) [Bodur&alt, 1982], propus mai nti n 1962 ca o tehnic manual i apoi pus la punct n anul 1966 de firma I.B.M., care realiza automatizarea unei pri a procesului de analiz, permind definirea unei baze de date minimale pentru un anumit sistem, precum i definirea unor importante operaii auxiliare pentru utilizarea eficient a respectivei baze de date. T.A.G. este definit ca o tehnic general aplicabil pentru proiectarea sistemelor informatice n domeniul comercial; ea i propune s asiste pe analist chiar din faza releveului informaional, cu o finalitate multipl: pentru colectarea i analiza datelor, pentru sistematizarea acestora n colecii sau fiiere i apoi pentru definirea fluxurilor informaionale prin activiti.
Tehnica T.A.G. apeleaz la principiul regresiv: se pornete de la ultimele ieiri ale sistemului supus cercetrii (ieiri pentru care analistul determin necesarul de informaii i-l nscrie pe un formular special); din acestea, T.A.G. determin necesarul de intrri pentru faza n amonte a fluxului informaional, grupndu-le dup momentul lor de apariie i apoi, iterativ, solicit analistului date .a.m.d. pn la primele intrri, din afara sistemului. n acest mod T.A.G. poate s defineasc o baz de date minimal pentru sistemul respectiv, cutnd totodat s reduc i durata total a fluxului informaional. Aceste procedee de analiz cu ajutorul grilei automatizate fac parte din tendina de abordare a problemelor nedecizionale dintr-un sistem, progresul fa de metodele din generaiile I i a II-a constnd doar n transferarea ctre calculator a unora dintre operaiile care erau efectuate manual. Preocuprile de a integra calculatorul n procesul de analiz sistemic s-au soldat cu elaborarea unor procedee care reuesc s automatizeze parial sau total unele din activitile de analiz. Ceea ce au n comun toate aceste procedee este faptul c ale se axeaz n exclusivitate asupra analizei i proiectrii sistemului informatic, asupra elaborrii automate a programelor i a corelrii lor ntr-un sistem. Cerinele sistemului se presupun a fi gata definite, ceea ce nseamn c analiza i proiectarea informaional decizional rmne s fie executate manual. Una dintre cele mai evoluate tehnici din aceast categorie (proiectarea sistemelor integrate) o reprezint sistemul I.S.D.O.S. (Information System Design and Optimization System), elaborat de un grup de cercettori de la Universitatea din Michigan, condui de profesorul Daniel Teichroew. Sistemul I.S.D.O.S. cuprinde mai multe metode care se nlnuie pentru a prelua specificaiile cerinelor, a le corela, a organiza etapele proiectrii sistemului informatic aferent, n scopul obinerii 1 cerinelor cu ajutorul unor grafuri A.D.C. i n final a elabora fiierele sistemului. Caracterizarea general a acestor procedee este faptul c ele sunt necomputerizate, ceea ce nu nseamn c nu se orienteaz spre promovarea unor metode de analiz logic riguroas i spre algoritmizarea operaiilor componente. Ceea ce le difereniaz radical este faptul c nu utilizeaz calculatorul n munca de analiz, ci momentul cnd este necesar folosirea lor n analiza de sistem. Tot n jurul anilor 1960 o serie de mari firme constructoare de calculatoare elaboreaz metodologii care ncearc s etapizeze i s sistematizeze operaiile necesare proiectrii unui sistem de conducere bazat pe utilizarea calculatoarelor. Cea mai reprezentativ metod este S.O.P. (Study Organizaion Plan), elaborat de firma I.B.M. Aceste metode sunt singurele care cuprind descrierea ntregii munci de analiz i proiectare a sistemelor, cu parcurgerea tuturor etapelor i fazelor, de la studii preliminare, pn la implementarea, bineneles la nivelul hardware - ului i software ului de atunci i fr a integra calculatorul n nsi munca de analiz. Aceste metodologii elaborate, n general, de diviziunile de cercetare ale marilor firme de calculatoare reprezint o poziie intermediar, de trecere de la metodologiile cu specific de analiz-proiectare a sistemelor pur informatice spre metodologiile A.S.I.D. metodologii de analiz i proiectare informaionaldecizional. Metodologii de tip informaional-decizional Metodologiile de analiz i proiectare informaional decizional pun la dispoziia analistului de sisteme procedee cuprinztoare i eficiente n vederea perfecionrii activitii social economice. Printre caracteristicile metodologiilor A.S.I.D. sunt diversitatea i mobilitatea lor; aceste metodologii
1
A.D.C. = analiza drumului critic, metod de conducere a aciunilor complexe Metodologii de realizare a sistemelor informatice 4343
nu formeaz nc un ansamblu unitar, standardizat, de reguli i prescripii, ci constituie elaborate unicat, destul de deosebite unul de altul n ceea ce privete terminologia, ct i n ceea ce privete mprirea n etape, subetape i faze i chiar n privina modului n care aplic ideea principal care st la baza lor regula prioritii aspectelor decizionale. O alt caracteristic important a metodologiilor A.S.I.D. o constituie abordarea problemelor i sectoarelor vitale ale societii, acelea n care problematicile decizionale sunt mai complexe i n care, prin optimizarea fluxurilor informaional decizionale, se pot obine avantaje considerabile. Tot att de nsemnat este i o alt trstur fundamental a metodologiilor A.S.I.D., i anume caracterul lor multidisciplinar (utilizarea unor metode i tehnici aparinnd metodologiilor de analiz de tip informatic, la care se adaug procedee preluate din cercetarea operaional, dinamica industrial, tehnici de simulare etc.). Care ar fi diferena dintre metodologiile de analiz proiectare a sistemelor informatice i cele de analiz i proiectare a sistemelor informaional decizionale ? n realitate, un sistem informatic va aparine ntotdeauna unui sistem informaional decizional, analiza pur informatic i de programare reprezentnd o subetap a analizei sistemului informaional decizional. Mai trziu s-au elaborat metodologii de analiz i proiectare informaional decizional de tip ameliorativ, care se orienteaz n special spre rezolvarea problemelor decizionale din sistem i care propun diverse procedee de integrare a metodelor cercetrii operaionale pentru optimizarea deciziilor din sistemul proiectat, precum i utilizarea psihosociologiei n nsi munca de analiz. Metodologiile ameliorative se caracterizeaz prin faptul c pleac de la sistemul informaional decizional real, n funciune, al unei societi sau al unei pri din aceasta i i propun mbuntirea acestui sistem, prelund tot ce este bun n el, dar n acelai timp transformnd ceea ce poate fi perfecionat. Deci sintetiznd se poate spune c metodologiile A.S.I.D. se pot grupa n dou mari categorii: metodologii care pornesc de la o exploatare prealabil ct mai amnunit a situaiei prezente a sistemului, procednd apoi, prin mbuntiri succesive, la elaborarea unui nou proiect de sistem adic metodologii ameliorative; metodologii ce i propun s construiasc un proiect de sistem, pornind de la descrierea (releveul) situaiei de fapt, ct i de la o analiz fundamental a obiectivelor pe care este chemat s le satisfac sectorul supus (re)proiectrii; acestea se cunosc sub numele de metodologii constructive sau aval amonte. Dintre cea mai cunoscut metod de analiz aval amonte este cea a lui Andr Delville, care a fost elaborat n Frana n anul 1966. La baza metodei aval amonte st ideea conform creia ntreg sistemul de elaborare, circulaie i prelucrare a informaiei trebuie construit de la obiectivele economice concrete ale societii. Cunoscnd obiectivele, printr-un procedeu deductiv se stabilesc informaiile n aval adic cele necesare realizrii obiectivelor (informaii care reprezint cerinele informaionale ale sistemului). Apoi, tot deductiv, se determin informaiile n amonte, adic necesare a fi prelucrate pentru obinerea informaiilor n aval i totodat procesele de prelucrare, inclusiv cele decizionale, prin care se transform informaiile din amonte n informaii aval. Procedeul se repet din aproape n aproape, urmrind din spre aval spre amonte ntreaga cascad informaional decizional pn se ajunge la informaiile care provin din afara sistemului i care reprezint informaiile de intrare. n etapa urmtoare se aleg mijloacele tehnice i metodele decizionale necesare i avantajoase pentru realizarea ntregii succesiuni de operaii informaional decizionale stabilite prin parcurgerea cascadei aval amonte.
Aadar, metoda Delville se caracterizeaz prin analiza informaional decizional combinat, cu ajutorul creia se construiete deductiv ntregul sistem plecnd de la necesiti informaionale legate de realizarea obiectivelor economice concrete, fr a ignora sistemul informaional existent din care se poate prelua ceea ce este eficient. Metoda are n vedere utilizarea tehnicilor moderne de prelucrare automat dar nu intr n detaliile proiectrii sistemului informatic. 4.3.2. Metodologii de analiz structurate Aceste metodologii au aprut n principal din nevoia de a rezolva criza software-ului (de a sistematiza i organiza o aplicaie) aprut n anii 1970-1980. Analiza structurat a unei aplicaii se bazeaz pe construirea unor diagrame de flux de date, aceasta fiind una dintre cele mai rspndite metodologii de inginerie a programrii. Dificultile au aprut, ns, pentru etapa de analiz structurat a unei probleme, etap care precede programarea; respectiv, a fost dificil de precizat cum trebuiau s arate i ce trebuiau s conin diagramele de flux de date. n acest sens, au existat mai multe abordri, dintre care se amintesc: Metodologia SADT (Structured Analysis and Design Technique), reprezint o metod grafic utilizat pentru analiza cerinelor i proiectare sistemelor. Forma s final a fost dezvoltat de Douglas T. Ross n anul 1974, scopul principal fiind nelegerea i specificarea cerinelor naintea nceperii realizrii efective a produsului software. Metodologia JSD (Jackson System Development). JSD este o metodologie definit de Cameron n 1989, reprezentnd o extensie a metodei JSP (Jackson Structured Programming). Metoda const n realizarea unei corespondene ntre structura problemei de rezolvat i structura unui program. Aceast metod este recomandat a fi utilizat n cadrul aplicaiilor care se bazeaz pe implementri secveniale i pe prelucrarea exclusiv a datelor de intrare (aplicaii financiare, bancare i de asigurri). Metodologia DSSD (Data Structured System Development), a fost introdus de Warnier n 1976. Ideea de baz pe care este construit metodologia este aceea c identificarea corect, precis a structurilor de date ale problemei de rezolvat va conduce la realizarea unui program bine structurat i deci bine proiectat. Utilizarea acestei metode este recomandat a fi utilizat pentru aplicaii care au drept obiectiv principal procesarea datelor. Metodologia SA/SD (Structured Analysis/Structured Design) presupune folosirea unor multitudini de diagrame pentru a descrie logic un sistem. Metodologia MERISE. Dezvoltarea metodei MERISE se datoreaz iniiativei ministerului francez al industriei, care a venit cu propunerea realizrii unei metodologii de analiz i proiectare a sistemelor informatice n timp real ce implic manipularea informaiilor stocate n baze de date. Scopul principal al acestei metode este acela de concepie a unui sistem informaional organizaional i informaizat. Metodologia Yourdon/Constantine, care mai este cunoscut i sub denumirea de proiectare structurat, folosete diagrama fluxului datelor pentru analiz, urmat de descompunerea funcional specific urmrind obinerea unor module stabile cu interconectare minim cu alte module. Ca faze principale enumerm: studiul i analiza sistemului existent, conceperea sistemului, proiectarea de detaliu, i elaborarea programelor. Metodologia Meyer, cunoscut i sub denumirea de proiectare compus, are drept obiectiv minimizarea relaiilor intermediare i maximizarea relaiilor intramodulare. Aceast metod permite o structurare a sistemului/programelor n funcie de fluxul datelor, specificndu-se ordinea de execuie a unei funcii de prelucrare elementare sau agregate. Metodologia MERISE Dezvoltarea metodei MERISE se datoreaz iniiativei ministerului francez al industriei, care a venit cu propunerea realizrii unei metodologii de analiz i proiectare a sistemelor informatice n timp real ce implic manipularea informaiilor stocate n baze de date.
Scopul principal al acestei metode este acela de concepie a unui sistem informaional organizaional i informatizat. n prezent exist un produs informatic AMC*Designer, care implementeaz metoda MERISE prin formalizarea automat a unii sistem informatic i elaborarea unei documentaii adecvate. n cadrul metodei MERISE se face o distincie ntre aspectul static i dinamic al sistemului informatic, pe de o parte, i viziunile de referin asupra acestui sistem (comunicaie; date, prelucrri sau tratamente; definiii, descrieri, instrumente auxiliare). Astfel, aspectul static al unui sistem informatic este reprezentat de comunicaii, definiii i descrieri, deoarece, n principiu, aceste elemente sunt invariante n timp. Rezult c aspectul static are n vedere latura semantic a unui sistem informatic. Aspectul dinamic este redat prin prelucrri i date, elemente ce au un anumit grad de variabilitate n raport strict cu evoluia traiectoriei ntregului sistem asociat unui organism. Din punct de vedere al metodologiei MERISE, se disting trei cicluri care modeleaz i dezvolt noul sistem informatic: ciclul de via (recursivitatea); ciclul de decizie (conducerea sau ciclul de validare); ciclul de abstractizare (raionamentul sau ciclul de modelare). Dac se utilizeaz reprezentarea tridimensional a acestor cicluri se obine urmtoarea abordare:
Abstracie model la nivel concepional model la nivel organizaional model la nivel fizic
Via
concepia sistemului informatic realizarea sistemului informatic meninerea sistemului informatic
Decizie
decizii globale decizii organizaionale decizii tehnice decizii funcionale
Fig. 4.1. Definirea etapelor de realizare a unui sistem informatic prin intermediul metodei MERISE Aceste cicluri asigur folosirea urmtoarelor elemente n realizarea unui sistem informatic:
Perioada de realizare, care este intervalul de timp n limitele cruia sunt realizate aspecte ale unui astfel de sistem, adic sunt construite i / sau utilizate componentele globale ale unui astfel de sistem. n realizarea efectiv a unui sistem informatic exist trei perioade fundamentale: Perioada de concepie asigur definirea soluiilor generale n termeni generali, evaluarea soluiilor de organizare i a celor tehnice, definirea complet a viitorului sistem informaional organizaional. Perioada de concepie are sarcina de a realiza punctul de vedere al utilizatorului. Perioada de realizare va asigura specificaiile tehnice complete ale viitorului sistem informaional informatizat, elaborarea procedurilor automate necesare, inclusiv punerea n Metodologii de realizare a sistemelor informatice 4646
funciune a noului sistem. Rezult c aceast perioad realizeaz punctul de vedere al realizatorului noului sistem. Perioada de meninere n funciune trebuie s asigure funcionarea efectiv, eliminarea anomaliilor aprute i, eventual evoluia sistemului realizat. Etapele (subetapele) sunt pri componente ale perioadei de concepie, realizarea i meninerea n funciune, prin intermediul crora se realizeaz anumite aspecte generale sau particulare ale proiectrii noului sistem informatic. Aceste etape vor asigura: vederea global asupra sistemului informaional organizaional; vederea extern, a utilizatorului sistemului informaional organizaional; vederea intern, a realizatorului sistemului informaional informatizat; vederea funcional, a organismului respectiv. Din cele prezentate rezult c pentru fiecare perioad de realizare exist etape specifice, prin intermediul crora se realizeaz vederile aferente noului sistem, astfel: Perioada Etapa Vederea asigurat De concepere schema directoare vedere directoare/global studiu de evaluare vedere extern studiu de detaliu vedere extern studiu organizaional vedere extern De realizare studiu tehnic vedere intern proiectarea procedurilor vedere intern implementarea vedere intern De meniune n exploatarea curent vedere funcional funciune ntreinerea vedere funcional dezvoltarea se noi versiuni vedere funcional
Fazele utilizate n realizarea unui sistem informatic sunt elementele componente ale unei etape, prin intermediul crora sunt realizate aspecte pur particulare ale unui segment unitar din structura sistemului informatic abordat.
n mod concret, proiectantul sistemului informatic deruleaz aceste trei stadii pe tot parcursul existenei noului sistem. Aceste cicluri se desfoar simultan prin intermediul etapelor de proiectare. De asemenea trebuie amintit c aceast metod utilizeaz ase nivele de abstractizare:
Nivelul global (NG) are rolul de a coordona toate celelalte nivele: conceptual, organizaional,
logic, fizic i exploatare. Nivelul conceptual (NC) acest nivel cuprinde componentele fundamentale pe care se va baza noul sistem informatic, independent de restriciile de organizare a organismului supus analizei sau de dotarea prezent sau viitoare cu tehnic de calcul i de comunicaie. Nivelul organizaional (NO) rezult din conversia nivelului conceptual, asigurnd organizarea comunicaiilor, datelor i prelucrrilor n raport cu cerinele compartimentale i umane. Nivelul logic (NL) rezult din conversia nivelului organizaional, realiznd detalierea acestuia prin partajarea activitilor ntre utilizatorii din compartimentele organismului i resursele practice de tehnic de calcul utilizate concret. Practic acest nivel poate conduce la mai multe variante de organizare a noului sistem informatic. Nivelul fizic sau operaional (NF) cuprinde stabilirea soluiilor tehnice pentru asigurarea comunicaiei, a datelor i a prelucrrilor pentru noul sistem informatic proiectat. Nivelul de utilizare sau exploatare (NE) acest nivel are ca surs nivelul fizic i se concretizeaz practic prin modelul de funcionare efectiv a noului sistem informatic proiectat. Nivelele conceptual i organizaional sunt adaptate concepiei sistemului informaional, n timp ce urmtoarele trei nivele sunt asociate proiectrii sistemului informaional informatizat.
Metoda MERISE folosete concepte specifice pentru fiecare nivel i proces de modelare deoarece aceasta trebuie s asigure urmtoarele deziderate fundamentale: 1. n plan vertical, metoda MERISE permite urmtoarele operaii: abstractizarea, asigurarea soluiei de organizare, alegerea soluiei tehnice, realizarea strii de exploatare. Aceste operaii sunt realizate succesiv, pornind de la nivelul conceptual, continund cu cel organizaional i terminnd cu cel de exploatare. 2. n plan orizontal, MERISE asigur trei nivele: nivelul de transmitere asigur trecerea de la prelucrrile locale ctre cele distribuite, nivelul de detaliu cuprinde transformarea de la general la particular, nivelul de descriere asigur conversia ntre nivelele conceptual , organizaional, logic, fizic i exploatare Conversia dintre planurile vertical i orizontal se asigur prin validri i interaciuni ntre diferite metode, aflate ns la acelai nivel de abordare. Concluzionnd se poate spune c proiectarea sistemelor informatice conform metodei MERISE trebuie s se bazeze pe cele trei cicluri. Ea presupune parcurgerea unor etape: elaborarea schemei directoare; studiul prealabil; studiul detaliat; studiul tehnic; elaborarea programelor; implementarea; meninerea n funciune a sistemului informatic. Etapele de elaborare a schemei directoare, studiul prealabil i studiul detaliat reprezint de fapt conceperea sistemului informatic. Studiul tehnic poate s fac parte din conceperea sistemului informatic sau din realizarea i lansarea lui n execuie. Realizarea i lansarea n execuie a sistemului informatic este alctuit din etapele: elaborarea programelor i implementarea sistemului.
Ciclul de decizie decizi globale decizii de organizare decizii tehnice
G C O L F
nivel global nivel conceptual nivel organizaional nivel logic nivel fizic
Studiul de evaluare Proiectarea conceptual
SE PC
perioada de concepie perioada de realizare perioada de meninere
Proiectarea organizaional PO Proiectarea logic Proiectarea fizic Implementarea Exploatarea curent PL PF IMP EXC INT
nivel exploatare
ntreinerea
Dezvoltarea de noi versiuni DNV Ciclul de abstractizare Ciclul de via
Schema directoare
Fig. 4.2. Corelaia ciclurilor metodei MERISE Metodologia MERISE utilizeaz modelul entitate relaie pentru analiza i proiectarea modelelor statice, i reele Petri pentru modelele dinamice.
MERISE nu utilizeaz diagramele de flux de date care fac legtura ntre modelul static i cel dinamic. De aceea, pentru a analiz i o proiectare complet i eficient a sistemelor informatice, se recomand utilizarea acestei metodologii n conjuncie cu alte tehnologii. Elementele care stau la baza operaiei de descriere a unui proces dinamic sunt urmtoarele elemente: evenimente, operaii i sincronizri. O schem general de construire a unui model MERISE cuprinde urmtorii pai: construirea diagramei de flux de date utiliznd o alt tehnologie; ordonarea informaiilor identificate i selectate; construirea unui model liniar MERISE; verificarea sincronizrii diferitelor operaii. Rezultatele utilizrii MERISE constau n crearea unei vederi de ansamblu asupra fluxului informaiilor, a ordinii temporale i a interdependenelor dintre acestea. Aceste informaii vor fi utile att la analiza, ct i la proiectarea sistemului.
Capitolul 5 Analiza i proiectarea orientat obiecte

5.1. Concepte utilizate n tehnologia orientat obiect
Proiectarea i analiza orientate obiect se bazeaz pe aa numitul model obiectual. Acesta a introdus principii precum abstractizarea, ncapsularea datelor, modularizarea, ierarhia i persistena. Nici unul din aceste principii nu este nou, dar ceea ce este important este faptul c toate aceste concepte sunt tratate mpreun, ncercnd armonizarea lor prin diferite tehnici. Tehnologia orientat obiect reprezint esena combinaiei a patru idei: [Meyer, 1997] Sistemele software permit anumite aciuni pe anumite tipuri ale obiectelor; pentru a obine un sistem flexibil i reutilizabil, este indicat ca structura acestuia s se bazeze pe tipuri de obiecte i nu pe aciuni. Conceptul care rezult este un mecanism mult mai puternic i multilateral numit clas, care n construirea softwareului orientat obiect servete ca baz att pentru structura modular ct i pentru tipul sistemului. O disciplin riguroas este o abordare corect a problemei construirii softwareului pe care aceasta trebuie s o suporte. Ideea este c orice sistem trebuie s fie tratat ca o colecie de componente care colaboreaz la ndeplinirea cu succes a sarcinilor. Principiul epistemologic se refer la ntrebarea cum pot fi descrise clasele. n tehnologia orientat obiect, obiectele descrise printr-o clas sunt definite numai de modul n care ele pot fi utilizate: operaiile (cunoscute i sub denumirea de caracteristici) i proprietile formale ale acestor operaii. Aceast idee este exprimat formal de teoria tipurilor de date abstracte. Tehnica de clasificare se ocup de observaiile n urma crora munca este mprit pe domenii. Softwareul nu face excepie, i metoda orientat obiect se bazeaz pe o clasificare cunoscut sub numele de motenire. Nu exist ndoieli asupra faptului c proiectarea orientat obiect este fundamental diferit fa de metodele aprute anterior. Ea necesit un mod diferit de percepie a problemelor, de nelegere a modului cum urmeaz s fie analizate, proiectate i implementate acestea. n centrul ateniei se afl noiunea de obiect (respectiv de clas), aceasta punndu-i amprenta asupra ntregului proces de proiectare i implementare. O abordare orientat obiect se axeaz mai nti pe identificarea obiectelor din domeniul supus analizei, i apoi se alege procedura potrivit. Putem spune, la o prim vedere, c termenul de orientat obiect nseamn organizarea software-ului ca o colecie de obiecte discrete, fiecare obiect ncorpornd att structuri de date, ct i comportament. Construcia fundamental n abordarea orientat obiect o constituie obiectul care combin structura datelor i comportamentul ntr-o singur entitate. Deci, un model orientat obiect va fi format dintr-un numr de obiecte care constituie pri bine delimitate ale sistemului modelat. [Vtui, 2000]
Obiectul este o entitate care se poate distinge dintre alte entiti i care are o semnificaie n contextul O metod structural care se aplic pentru descompunerea i reutilizarea softwareului.
aplicaiei modelate. Tot prin obiect se nelege ceva asupra cruia se poate ntreprinde o aciune sau care poate ntreprinde o aciune asupra altui obiect.
Analiza i proiectarea orientat obiect 5050
Un obiect poate fi considerat o entitate care ncorporeaz att structuri de date (denumite atribute), ct i comportament (numite operaii). Pentru a fi un obiect, entitatea respectiv trebuie s aib urmtoarele caracteristici:
Identitatea: obiectul este o entitate discret, care se distinge dintre alte entiti. Clasificarea: obiectele cu aceleai atribute i operaii se grupeaz n clase. Fiecare obiect poate
fi considerat drept o instan a unei clase. Polimorfismul: aceeai operaie (cu acelai nume) poate s aib comportament diferit n clase diferite. Implementarea concret a unei operaii ntr-o anumit clas se numete metod. Motenirea: atributele i operaiile se transmit de-a lungul claselor bazate pe o relaie ierarhic.
Fiecare obiect este unic i se caracterizeaz prin: Identitate: nseamn c obiectele se disting ntre ele prin existen i nu prin atributele lor. G. Booch definete identitatea ca fiind acea proprietate a unui obiect care-l distinge de alte obiecte . Jim Rumbaugh definete identitatea astfel:o caracteristic distinctiv a unui obiect care indic existena separat a obiectului chiar dac obiectul respectiv are aceeai valoare ca un alt obiect. Stare: cuprinde toate atributele (de regul, statice) ale unui obiect mpreun cu valorile curente (de regul, dinamice) ale acestor atribute. Atributul poate fi o valoare simpl sau un alt obiect, iar starea unui obiect influeneaz comportamentul su la primirea unui nou mesaj. G. Booch definete starea unui obiect un set de valori pstrate n mod curent de atributele sale. Comportament: reprezint activitatea s testabil i vizibil din exterior, el arat modul cum un obiect acioneaz i reacioneaz, n termenii schimbrii strii i comunicrii prin mesaje G. Booch. Construirea modelului obiectelor este etapa cea mai important a metodologiei utilizate i reprezint punerea n eviden att a obiectelor, cu atributele i operaiile proprii, ct i a relaiilor dintre ele. Modelul obiectelor reprezint modelul static al unei aplicaii. Un model este o noiune abstract i este construit pentru a nelege problema nainte de a implementa soluia. Cadrul conceptual, pentru abordarea orientat obiect, l constituie modelul obiectului care cuprinde urmtoarele principii: Abstractizarea const n surprinderea aspectelor eseniale ale unei entiti, ntre anumite entiti, situaii sau procese din lumea real i concentrarea numai asupra acestor similariti ignornd diferenele dintre ele. De asemenea, abstractizarea presupune omiterea prilor sistemului care nu sunt necesare pentru nelegerea sistemului la un anumit nivel de detaliu. Accentul, pentru un obiect, se pune pe ce este acesta i pe ce trebuie s fac, nainte de a stabili concret detaliile de implementare. Acesta este motivul pentru care, n crearea unei aplicaii orientate obiect, etapa esenial este cea de analiz i nu de implementare. ncapsularea (ascunderea informaiilor) este un principiu al abordrii orientate obiect care prevede ca obiectele s constituie entiti de sine stttoare; atributele unui obiect nu sunt accesibile utilizatorului n mod direct, ci doar prin intermediul metodelor definite, care astfel trebuie s se constituie ntr-un set ct mai complet de operaii relative la obiect. ncapsularea este un principiu derivat al abstractizrii i const n separarea aspectelor externe ale unui obiect, care sunt accesibile altor obiecte, de aspectele implementrii interne ale obiectului, care sunt ascunse celorlalte obiecte, ceea ce face posibil modificarea implementrii obiectului fr a afecta aplicaiile care-l utilizeaz. Ea este legat de securitatea programrii, furniznd un mecanism care asigur accesul controlat la starea i funcionalitatea obiectelor. Potrivit acestui mecanism, o clas trebuie s aib membrii mprii n dou seciuni: partea public, care este constituit din atributele i metodele pe care obiectele le ofer spre utilizare altor obiecte (reprezint partea de interfa a obiectului respectiv), i partea privat, care cuprinde atributele i/sau metodele care servesc exclusiv obiectelor clasei respective (rmn inaccesibile utilizatorului).
Modularizarea reprezint mprirea sistemului n obiecte individuale cu legturi minime ntre ele. Acest principiu ajut n munca de programare, deoarece duce la reducerea complexitii unui program, prin mprirea acestuia n module mai mici, uor de modificat i de implementat. Ierarhizarea reprezint ordonarea pe diferite niveluri a abstraciilor. Dup Grady Booch, cele mai importante tipuri de ierarhii ale unui sistem complex sunt: ierarhia is-a, adic apartenena unei clase la o familie de clase de nivel mai nalt, ceea ce se traduce prin conceptul de motenire; ierarhia is-part-of, adic apartenena unei clase la o alt clas, n calitate de component, ceea ce duce la apariia relaiei de tip parte-ntreg (whole-part). mpachetarea datelor i a comportamentului n acelai obiect, se refer la faptul c un obiect
conine att structuri de date, ct i de operaii, i este util n cazul n care exist mai multe operaii cu acelai nume n clase diferite (n acest fel se va ti ntotdeauna crei clase i aparine o anumit metod). Existena unor operaii (metode) diferite cu acelai nume, dar cu comportament diferit, se numete polimorfism.
Partajarea. Acest concept este utilizat la diverse nivele. Astfel ea poate nsemna transmiterea
acelorai structuri de date i operaii de-a lungul unor clase dintr-o ierarhie de clase. Dac o clas motenete o alt clas, atunci ea motenete toate atributele i operaiile clasei de baz, iar din punct de vedere al codului, acestea sunt identice cu cele ale clasei de baz, i nu copii ale lor. O clas de obiecte descrie o mulime de obiecte cu atribute similare, comportament similar (operaii) i relaii similare cu alte obiecte din sistem. Denumirea de clas de obiecte se poate utiliza similar cu denumirea de clas, iar n loc de obiect care aparine unei clase se poate utiliza noiunea de instan a unei clase, fiecare obiect fiind o instan a unei clase. Obiectele din aceeai clas au o serie de atribute comune i un comportament comun. Dup cum se observ din figura 5.1., o clas poate fi:
Clas abstract, este acea clas care nu are instane directe, dar ai crei descendeni (subclase)
au instane directe.
Clas concret este o clas cu instane directe. O clas concret poate avea subclase
(descendeni) abstracte, dar care, la rndul lor, trebuie s aib descendeni concrei. Pentru uurarea descrierii se utilizeaz diferite diagrame de reprezentare a claselor i obiectelor. Fiecare autor al unei metode de analiz i proiectare i creeaz propriile notaii pentru diagramele folosite. Deosebirile ntre diferite abordri se refer mai mult la notaii dect la noiunile utilizate, conceptele de baz fiind n mare parte aceleai.
Fig. 5.1. Model de definire a claselor ntr-o metod orientat obiect La fel ca i obiectele, clasele au o viziune intern i una extern. Viziunea extern a unei clase este dat de interfaa sa, care este format din declaraii privind toate operaiile aplicabile clasei, dar poate include i declaraii ale altor clase constante etc. Interfaa poate fi:
Public, ceea ce nseamn c ea este accesibil tuturor clienilor si. Protejat, n acest caz clasa este accesibil numai clasei nsi, subclaselor sale i claselor
prietene. Privat, clasa este accesibil numai clasei nsi i claselor prietene. Starea unui obiect trebuie s aib o anumit reprezentare n clasa din care face parte. Acest lucru se realizeaz sub form de declaraii de constante i variabile plasate n zona protejat sau privat a interfeei clasei. n acest mod, reprezentarea comun a tuturor instanelor unei clase este ncapsulat i modificarea reprezentrii nu va afecta funcionalitatea nici unui obiect.
Implementarea clasei reprezint viziunea s intern care este format din toate operaiile definite n
interfaa clasei. Un atribut reprezint o caracteristic a unei clase care are asociat un identificator i un tip. Valoarea pe care o poate lua un atribut trebuie s fie compatibil cu tipul su. Un atribut care poate fi calculat din alte atribute se numete atribut derivat.
Constrngerile sunt legturi funcionale ntre entitile
(obiect, clas, atribut, legtur sau asociere) din cadrul unui model al obiectelor. O constrngere restricioneaz valorile pe care le poate lua entitatea. O constrngere asupra unei legturi poate fi ilustrat prin exemplu din figura 5.2.:
Constrngeri asupra unei legturi
Constrngeri asupra unui atribut
Fig. 5.2. Constrngeri asupra unei legturi i a unui atribut O clas poate s conin i constrngeri asupra atributelor (figura 5.2., data_fact>01.01.2004). Acestea se numesc restricii. Ele se pot aplica i asupra unei subclase. De exemplu, un ptrat este un paralelipiped cruia i se pune condiia ca toate laturile s fie egale; un cerc este o elips cu condiia ca ambele semiaxe s fie egale. O operaie care face parte dintr-o clas este o funcie care se aplic obiectelor aparinnd clasei respective. Fiecare operaie are ca argument implicit clasa din care face parte. Operaia poate fi polimorfic, adic aceeai operaie poate apare n mai multe clase diferite. O clas abstract poate si defineasc nite operaii, dar fr s le implementeze. Aceste operaii se vor numi operaii abstracte. O subclas poate s redefinesc i o operaie a unei superclase, aceasta numindu-se redefinire (overriding).
Operaia unui obiect este o aciune pe care un obiect o execut asupra altui obiect pentru a primi o reacie din partea acestuia. Un mesaj este o operaie pe care un obiect o execut asupra altui obiect. O operaie reprezint un serviciu pe care o clas l ofer clienilor si. Cele cinci tipuri de operaii pe care
un client le poate executa asupra unui obiect sunt:
Modificare n urma operaiei starea unui obiect se modific. Selectare operaia acceseaz starea unui obiect fr a o modifica. Iterare operaia acceseaz toate prile unui obiect ntr-o ordine bine definit. Constructor operaia prin care se creeaz un obiect i/sau se iniializeaz starea sa. Destructor operaia prin care se distruge obiectul i/sau se elibereaz starea sa. Metoda reprezint implementarea concret a unei operaii pentru o anumit clas. Numrul i
tipul argumentelor, mpreun cu tipul valorii returnate, se numete semntura unei operaii. Obiectele contribuie la comportamentul sistemului colabornd cu alte obiecte. Pentru a stabili relaiile i asocierile ntre obiecte se utilizeaz legturi i asocieri. O legtur este o conexiune fizic sau conceptual ntre obiecte. Din punct de vedere matematic, o legtur este un tuplu, adic o list ordonat de instane de obiecte. Ca participant la o legtur, un obiect poate juca unul din urmtoarele roluri:
Actor este un obiect care acioneaz asupra altor obiecte, dar asupra cruia nu poate aciona alt
obiect.
Server este un obiect pe care pot opera alte obiecte, dar el nu poate opera niciodat asupra altor
obiecte. Agent este un obiect care opereaz asupra altor obiecte i asupra cruia pot opera alte obiecte. Un agent lucreaz n numele unui actor sau unui alt agent. Pe de alt parte, o legtur este o instan a unei asocieri. O asociere descrie un grup de legturi cu aceeai structur i aceeai semantic i sunt cele mai frecvente relaii existente ntre clase. Legturile sunt de mai multe tipuri:
Unu la unu (one-to-one), caz n care unei clase i corespunde numai o singur clas.
Fig. 5.3. Diagrama claselor (legtur unu la unu)

Unu la muli (one-to-many), n aceast situaie unei clase i pot corespunde mai multe clase.
Fig. 5.4. Diagrama claselor ntr-o legtur unu la muli

Muli la muli (many-to-many), este cazul n care fiecrei clase care particip ntr-o astfel de
legtur i vor corespunde mai multe clase.
Fig. 5.5. Diagrama claselor ntr-o legtur muli la muli Din punct de vedere al numrului de clase care particip la o asociere aceasta poate fi: binar, ternar i n-ar. Asocierile sunt caracterizate prin multiplicitate i prin ordonarea obiectelor (opional) unei clase care particip la asociere. Termenul de multiplicitate arat cte instane ale unei clase pot fi legate de o singur instan a unei alte clase. Multiplicitatea este descris prin numrul de instane care intervin n legtur, trecut n dreptul liniei la unul sau la ambele capete ale ei (0, 1, 0..*, 1..*, 0..1, *). De multe ori este necesar, ca n cadrul unei asocieri muli s se specifice dac ordonarea este important. n acest caz se va utiliza simbolul {ordered} n dreptul asocierii. Ordonarea este un caz particular de constrngere asupra asocierii (capitolele unei cri sunt ordonate n cuprinsul acesteia). Asocierile, la fel ca obiectele, pot avea un nume i atribute. Uneori este necesar ca relaia de asociere s fie modelat ca o clas, fiecrei legturi corespunzndu-i o instan a clasei respective. Ceea ce este important de reinut este faptul c aceast nou clas nu poate s existe n absena claselor de care este dependent (figura 5.6.).
Fig. 5.6. Asociere clasificabil Un alt termen utilizat n conjunctur cu cel de asociere este cel de rol, care reprezint captul unei asocieri. Astfel, ntr-o asociere binar fiecrui capt i se poate atribui un rol (nume), care are un neles n contextul aplicaiei. Numele unui rol identific n mod unic captul respectiv al asocierii. Se recomand utilizarea numelor de roluri n cazul n care asocierile sunt ntre obiectele aceleiai clase. O asociere poate fi calificat. O asociere calificat leag dou clase de obiecte i un calificator, reprezentnd un atribut special care reduce efectul multiplicitii unei asocieri. Dac exist o asociere de tip unu la muli sau muli la muli, atunci folosirea unui calificator n partea muli va identifica n mod unic obiectul respectiv. De exemplu: ntre clasa Departament i Angajat exist o legtur de unul la mai muli. Deci un departament poate avea unul sau mai muli angajai, dar un angajat lucreaz numai ntr-un singur departament; utilizarea calificatorului nume_angajat reduce asocierea unu la mai muli la o asociere unul la unul, ntruct un departament i un nume de angajat identific unic un angajat.
Agregarea este o relaie special, de tip parte-ntreg (partwhole) sau parte-din (a-part-of), n care
anumite obiecte reprezentnd componente ale unui ntreg sunt asociate cu acel obiect, care reprezint ntregul, sau altfel spus agregarea este o relaie care leag o clas ansamblu cu o clas component,
fiind o form special de asociere, i nu un concept n sine, cu urmtoarele proprieti: este tranzitiv i asimetric. Deci o clas agregat este definit ca o clas a crei structur const din unul sau mai multe obiecte simple. Agregrile pot fi clasificate n trei categorii:
Agregare fix: clasa agregat const dintr-un numr fix de componente, deci agregarea are o structur fix (numrul i tipurile prilor sunt predefinite). De exemplu un Ptrat are patru Unghiuri i patru Laturi. Agregare variabil: clasa agregat const dintr-un numr finit de elemente, dar numrul de elemente poate varia. De exemplu, un Act Adiional poate avea un numr variabil de Servicii. Agregare recursiv: conine, direct sau indirect, o instan a aceluiai tip de agregare. Numrul de nivele posibil este nelimitat. De exemplu, un Termen este o generalizare a clasei Expresie, dar clasa Expresie este format din Termeni.
Fig. 5.7. Relaii de agregare O posibil rafinare a unei asocieri o reprezint relaia de utilizare care permite accesul clientului numai la interfaa public a furnizorului.
Generalizarea este relaia dintre o clas i una sau mai multe versiuni mai rafinate ale ei. Clasa care se rafineaz se numete clas de baz, sau superclas, iar fiecare versiune mai rafinat se numete clas derivat, sau subclas. Atributele i operaiile comune unui grup de subclase sunt
grupate n superclas i se spune c sunt motenite de fiecare subclas. Fiecare subclas are i propriile atribute i operaii. Generalizarea poate avea mai multe niveluri (maximum 2-3), iar generalizarea i motenirea sunt tranzitive prin aceste niveluri. Generalizarea este o construcie util att pentru modelarea conceptual ct i pentru implementare i faciliteaz modelarea structurnd clasele i evideniind similitudinile i diferenele ntre clase. Motenirea operaiilor este util n implementare pentru c permite reutilizarea codului.
Fig. 5.8. Generalizarea
O caracteristic important a unui sistem este dat de caracterul su dinamic, iar pentru descrierea acestuia se vor utiliza o serie de concepte, care la rndul lor vor fi folosite pentru realizarea modelului dinamic al sistemului. La un moment dat un obiect se afl ntr-o anumit stare, reprezentat prin mulimea valorilor tuturor atributelor i legturilor obiectului. Ca urmare a unor stimuli externi, numii evenimente, starea unui obiect poate s se schimbe n timp. Pentru fiecare obiect, aceast schimbare este reflectat de diagrama dinamic a obiectului respectiv. O stare este deci o abstractizare a valorilor atributelor i legturilor unui obiect, care specific rspunsul unui obiect la un eveniment. Astfel, un obiect rmne ntr-o stare atta timp ct nu apar evenimente externe. Trecerea dintr-o stare n alta, cauzat de un eveniment extern, se numete tranziie. Un eveniment este o modificare a contextului, care are loc la un anumit moment de timp i nu are durat. Dou evenimente pot fi legate unul de cellalt astfel: un eveniment poate s precead sau s succead logic altui eveniment (deci s fie condiionat de acesta), sau cele dou evenimente s nu fie condiionate reciproc (ele nu se pot influena unul pe altul). Despre dou evenimente necondiionate se spune c sunt concurente i n acest caz ele pot s apar simultan. Un eveniment este o transmisie unidirecional de informaie de la un obiect la altul. O diagram de stare descrie comportamentul unei singure clase (modelul dinamic este o colecie de diagrame de stare, care interacioneaz unele cu altele prin evenimentele partajate). Astfel cnd un obiect recepioneaz un eveniment, starea s urmtoare depinde att de starea curent, ct i de evenimentul recepionat. Diagrama de stare reflect toate strile posibile ale unui obiect al unei clase, obiect care poate avea un ciclu de via finit sau infinit. O diagram de stare este un graf ale crui noduri sunt strile i ale crui arce sunt tranziiile ntre stri. Toate tranziiile din aceeai stare trebuie s corespund unor evenimente diferite. O astfel de diagram este reprezentat n figura 5.9. O diagram pentru un obiect cu via finit are o stare de pornire (iniial) i una de sosire (final).
Simpl
Cu condiii
Fig. 5.9. Diagrama de stri pentru un automat de scos bani O condiie este o funcie boolean avnd drept parametri obiecte. Condiiile pot fi folosite pentru a stabili momentul cnd va avea loc o anumit tranziie. O tranziie condiional se execut numai atunci cnd apare evenimentul i condiia corespunztoare este ndeplinit. Diagramele de stare nu specific numai evenimentele, ci ele descriu i ce face un obiect, ca rspuns la un eveniment. Rspunsul obiectelor este descris de operaii, care pot fi de dou tipuri:
Activitatea este o operaie care are o anumit durat (necesit un interval de timp pentru a fi executat). Ea este asociat unei stri i se execut n starea respectiv. O activitate implic o operaie continu, ca de exemplu meninerea unei ferestre pe ecran. Reprezentarea unei activiti se face, n diagrama de stri, prin cuvntul do:, urmat de ce se realizeaz. Aciunea este o operaie instantanee. Ea este asociat cu un eveniment. Notaia pentru o aciune este slash (/) urmat de numele aciunii care succede evenimentului ce a produs aciunea. Analiza i proiectarea orientat obiect 5757
Trebuie reamintit faptul c modelul dinamic specific secvene permise de transformri ale obiectelor din modelul obiectelor. O diagram de stare descrie toat sau o parte din comportarea unui obiect al unei clase date. Strile sunt clase de echivalen ale valorilor atributelor i legturilor unui obiect. Evenimentele pot fi reprezentate ca operaii n modelul obiectelor. Modelul dinamic al unei clase este motenit de subclasele sale, acestea motenind att strile, ct i tranziiile superclasei.
5.2. Limbajul unificat de modelare - UML

UML (Unified Modeling Language) a fost conceput cu scopul de reuni elementele cele mai
semnificative ale tuturor metodelor de modelare i analiz cunoscute pn n acel moment (anul 1994) i de a furniza un mecanism eficient de dezvoltare a programelor, dar mai ales de a impune o metod unic de analiz. Aceast operaie de unificare prezint anumite avantaje i dezavantaje.[Chiorean, 1998] Avantaje: eliminarea unor diferene de concepie i de notaie; eliminarea conceptelor ce nu s-au dovedit viabile i pstrarea celor care s-au dovedit utile. Dezavantaje: introducerea inevitabil a unui numr de noi concepte, sporind astfel complexitatea metodei; fiecare metod prezentat pn n acest moment inea cont de anumite particulariti ale problemelor, ceea ce nu mai este posibil n noul context. UML (Unified Modeling Language) furnizeaz o arhitectur pentru analiza i proiectarea obiectual a unui sistem cu unul din limbajele corespunztoare pentru specificarea, vizualizarea, construirea i documentarea sistemului software executat de proiectant i pentru modelarea afacerilor i a altor sisteme non-software. Aceast specificare reprezint convergena celor mai bune metode practice utilizate n industria tehnologiei obiectuale. UML este succesorul, am putea spune cel mai bun pentru limbajele de modelare obiect, al celor trei metode precedente orientate obiect, i anume, Booch, OMT i OOSE, incluznd n plus expresivitate n manipularea problemelor de modelare pe care aceste trei modele nu le utilizeaz pe deplin. Unul dintre scopurile principale ale UML a fost acela de a mbunti situaia industriei software prin asigurarea interoperabilitii instrumentelor de modelare vizual a obiectului. Totui, pentru a permite schimbul corect al modelului informaional ntre instrumente, este necesar o convenie n ceea ce privete semantica i notaia utilizat. n acest scop, UML ndeplinete urmtoarele condiii: Definirea formal a metamodelului comun de analiz i proiectare a obiectului (OA&D) reprezint semantica modelului OA&D, care include modele statice, modele comportamentale, modele de utilizare i modele structurale. Specificaii IDL (Interface Definition Language) pentru mecanisme care s asigure interoperabilitatea modelului ntre instrumente OA&D. Acest document include un set de interfee IDL care ajut la crearea unei construcii dinamice i a unei linii transversale de intersecie a modelului utilizat. Notaie convenional (human-readable) pentru reprezentarea modelelor OA&D. UML prezint o grafic elegant pentru a prezenta pe larg semantica sa bogat. Notaia este o component esenial a modelrii OA&D i UML. Totul a pornit de la OMG (Object Management Group) al crui obiectiv este de a asigura dezvoltarea tehnologiei obiectuale i influenarea ei n direcia stabilit de OMA (Object Management Architecture), care furnizeaz infrastructura conceptual pe care toate specificaiile OMG sunt
bazate. Adoptarea de ctre OMG a specificaiei UML reduce gradul de confuzie n cadrul industriei limbajelor de modelare i permite schimbul reciproc ntre instrumentele de dezvoltare vizuale utilizate. 5.2.1. Evoluia limbajului UML
Precursori UML: limbajele de modelare orientate obiect au nceput s apar la nceputul anilor 1970,
i n 1980 existau deja o varietate de metodologii experimentale cu diferene apropiate fa de analiza i proiectarea orientat obiect. Unele dintre aceste tehnologii au influenat aceste limbaje, printre care enumerm modelarea entitaterelaie (Entity-Relationship modeling), SDL (Specification & Description Language) i alte tehnologii. Numrul acestor limbaje de modelare a crescut n perioada 19891994 de la 10 la mai mult de 50. La mijlocul anilor 1990, au nceput s apar noi variante ale acestor metode, cel mai reprezentativ fiind modelul Booch93, dezvoltarea modelului OMT, i Fusion. Aceste metode ncep s ncorporeze tehnici unele de la altele, i astfel apar metodele OOSE, OMT-2, i Booch93 mbuntit. UML a fost dezvoltat de Rational Software i partenerii si. Efortul de unificare a nceput oficial n octombrie 1994 cnd Grady Booch i Jim Rumbaugh de la Rational Software Corporation ncep unificarea metodelor Booch i OMT. Prima versiune UML, numit Unified Method, (UML 0.8) a aprut n octombrie 1995. n toamna aceluiai an, Ivar Jacobson, i compania lui Objectory, se altur companiei Rational; i se ncorporeaz i metoda OOSE. Ca autori ai celor trei metode Booch93, OMT, i OOSE, Grady Booch, Jim Rumbaugh, i Ivar Jacobson au motivat crearea unui limbaj unificat de modelare din trei puncte de vedere: 1. Aceste metode au evoluat cu scopul de a fi independente unele fa de altele. 2. Prin unificarea semanticii i notaiei, aceste metode ar putea aduce o anumit stabilitate pe piaa de produse orientate-obiect. 3. Ei sperau ca aceast colaborare s nlture incovenientele celor trei metode. Efortul lor s-a concretizat n apariia documentaiei pentru variantele UML 0.9 i UML 0.91, n perioada iunieoctombrie 1996. Din acest moment n dezvoltarea acestui limbaj i-au depus eforturile i firmele: Digital Equipment Corp., HP, I-Logix, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, Texas Instruments, Intellicorp i Unisys. Aceast colaborare a condus la realizarea unui limbaj de modelare puternic, expresiv, foarte bine definit, i cu aplicabilitate general, numit UML. n ianuarie 1997 IBM & ObjectTime, Platinum Technology, Ptech, Taskon & Reich Technologies, i Softeam propun separarea RFP (Request For Proposal care din 1996 a fost obiectul OMG) de OMG. Prima versiune, care a fost publicat i propus aprobrii OMG n ianuarie 1997, a fost UML 1.0 care cuprindea urmtoarele documente principale: UML Semantics; UML Summary; UML Notation Guide; UML Process-Specific Extensions, i drept surse secundare urmtoarele documente: OMA; CORBA 2.0; Object Analysis & Design RFP-1; Rational Process. OMA, CORBA 2.0 i Object Analysis & Design RFP-1 au fost utilizate pentru a susine acordul OMG i a furniza termenul de obiect distribuit care completeaz UML-ul, iar Rational Process pentru a furniza termenii de proces i arhitectur care completeaz, de asemenea UML-ul. Diagrame iniiale care au fost propuse sunt: Diagrama cazurilor de utilizare; Diagrama claselor; Diagrame de comportament: Diagrama de stare; Diagrama de activitate; Diagrama secvenial;
Diagrama de colaborare; Diagrame de implementare: Diagrama de componente; Diagrama de aplicaie. mbuntirile aduse acestei prime variante au condus la apariia n iulie 1997 a versiunii UML 1.1, care a fost acceptat spre publicare n septembrie 1997, i adoptat n 14 noiembrie 1997, devenind astfel standard OMG. Drept diagrame au fost propuse cele nou diagrame de la versiunea 1.0 cu singura deosebire c diagrama secvenial i de colaborare au fost grupate n diagramele de interaciuni. Documentele necesare a fi parcurse pentru nelegerea primei variante a limbajului, UML 1.1, sunt:
UML Semantics, acest document definete semantica utilizat de UML (metamodelul UML). UML Notation Guide, specific sintaxa grafic (diagramele) utilizate pentru exprimarea
semanticii folosite de metamodelul UML (prezentarea metodei). OCL (Object Constraint Language) Specification, definete sintaxa OCL, semantica, i gramatica utilizat (instrumentul necesar nelegerii limbajului). Dar pentru nelegerea deplin mai trebuiesc parcurse i urmtoarele documente:
OA&D CORBAfacility Interface Definition specific o interfa de interoperabilitate instrument utiliznd CORBA IDL. Acest document specific interfeele pentru CORBAfacility pentru Object Analysis & Design, consecvent cu UML v.1.1. OA&D Facility reprezint un depozit pentru modele exprimate n UML. Uurina (ndemnarea facility) permite crearea, memorarea, i manipularea modelelor UML, deoarece permite o varietate larg a capacitilor de dezvoltare bazate pe model, incluznd: Desenarea modelelor UML n alte notaii i UML; Aplicarea unor procese i metode n stilul liniilor directoare; Matrici, interogri, i rapoarte; Automatizarea activitilor dezvoltrii ciclului de via. O prim directiv a OA&D Task Force este de a realiza interoperabilitatea semantic ntre instrumentele OA&D. Figura urmtoare descrie mai multe alternative pentru schimbarea informaiei de model ntre instrumente.
Tool 1 R e p o s it o ry w r it e MetaObject Fac ili t y o r R e p o s it o ry
Tool 2 read
M o d e l T ra n s f er
In t e r m e d ia t e S t r e a m /F ile O b je c t Analysis & D e s ig n F a c i li t y
Model Acce ss
Fig. 5.10. Alternative de model partajat ntre instrumente OA&D Repository Dou instrumente pot interfaa ctre acelai depozit i accesa un model de aici. MOF (MetaObject Facility) poate fi acest depozit.
Model Transfer Dou instrumente pot nelege acelai format de structur i schimba modele prin aceast structur, care poate fi un fiier. RFP face referire la acest format drept import facility. Avnd aceast interfa va fi necesar furnizarea unei ci pentru instrumente care nu sunt implementate ntr-un API (CORBA sau non CORBA) sau mediu de lucru depozit. Model Access Dou instrumente pot schimba modele pe o baz detaliu-prin-detaliu. RFP-ul se refer la aceast metod ca o facilitate de conectivitate connection facility. UML Proposal Summary face un sumar a propunerii OMG i discut relaia UML-ului cu alte tehnologii, incluznd meta-metamodelul MOF. Alte documente cuprinse n aceast versiune sunt: UML Extension for the Objectory Process for Software Engineering; UML Extension for Business Modeling. Principalele deosebiri dintre versiunile UML 1.0 i UML 1.1 erau: Creterea formalismului; Unificarea semantici interaciuni i colaborrii; Simplificarea modelului interfeei / tipului / clasei; Unificarea semanticilor relaiilor; Extinderea semantici managementului modelului, incluznd modele i subsisteme; Extinderea semanticii cazului de utilizare; mbuntirea structurii mpachetrii; mbuntirea transpunerii notaiei ctre semantic. A urmat n 1998 UML 1.2; n 1999 UML 1.3; n mai 2001 UML 1.4; tot n 2001 UML 1.5 RTF (Revision Task Force); i n 2002 UML 2.0 RFP. Mai trebuie amintit c din 1994 i pn la 17 ianuarie 1997 s- au nregistrat 5 propuneri distincte, dintre care cele mai importante au fost UML (Unified Modeling Language), OML (Open Modeling Language) i Object Time (IBM). n martie 2003 a fost standardizat versiunea UML 1.5, numit i Unified Modeling Language Specification. Specificarea UML 1.3 cuprinde: UML Summary UML Semantics UML Notation Guide UML Standard Profiles: Software Development Processes Business Modeling UML CORBAfacility Interface Definition UML XML Metadata Interchange DTD Object Constraint Language Principalele deosebiri dintre UML 1.2 (i UML 1.1) i UML 1.3 sunt: Modificarea relaiilor folosite ntre cazurile de utilizare. UML 1.1 avea dou relaii ntre cazurile de utilizare <<uses>> i <<extends>>, amndou fiind de fapt stereotipuri ale relaiei de generalizare. UML 1.3 are trei relaii: <<include>>, care este un stereotip al relaiei de dependen, i ea nlocuiete utilizarea lui <<uses>>; relaia de generalizare, i <<extends>>, un stereotip al relaiei de dependen. Diagrama de activitate. Modificrile se refer la utilizarea barelor de sincronizare, care sunt de bifurcaie i de reuniune, la concurena dinamic etc. Din anul 2002 versiunea UML 2.0 este propus pentru evaluare (proposals under evaluation). n aceast versiune exist 13 diagrame i cuprinde 4 componente: UML Infrastructure UML Superstructure OCL (Object Constraint Language)
UML Diagram Interchange Dintre firmele care utilizeaz UML drept standard n procesele de dezvoltare i producie, care acoper o gam larg de discipline, precum modelarea afacerilor, managementul resurselor, analiz i proiectare, programare, enumerm: Data Access Corporation, Electronic Data Systems Corporation, Enea Data, Hewlett-Packard Company, IBM Corporation, I-Logix, ICON Computing, IntelliCorp and James Martin & Co (James Odell), OAO Technology Solution,ObjectTime Limited, Oracle Corporation, PLATINUM Technology Inc., Rational Software (Grady Booch, Ivar Jacobson,Jim Rumbaugh), SAP, SOFTEAM, Sterling Softwrae, Taskon, Unisys Corporation. UML este mbuntit n continuare prin intermediul unei echipe, conduse de Cris Kobryn, formate din personaliti precum: James Odell, Dilhar DeSilva, Martin Griss, Eran Gery, Karin Palmkvist, Guus Ramackers, Bran Selic, Sridhar Iyengar, Gunnar Overgaard, i Jos Warmer. De asemenea, Grady Booch, Ivar Jacobson, i Jim Rumbaugh lucreaz n echip pentru mbuntirea acestuia, datorit experienei lor n acest domeniu. Exist de asemenea contribuii individuale cum ar fi: Peter Coad, Tim Harrison, Bertrand Meyer, Bill Premerlani, Ed Yourdon, Oliver Wiegert, i muli alii. O succint evoluie a UML-ului este prezentat n figura 5.11.
Fig. 5.11. Evoluia limbajului de modelare UML UML a fost selectat drept standard al limbajelor de modelare orientate-obiect (OOML Object Oriented Modeling Language) de ctre OMG n noiembrie 1997, i este utilizat de dezvoltatorii de produse software. Aceast specificare reprezint convergena celor mai bune metode practice utilizate n industria tehnologiei obiectuale i care au avut succes n modelarea sistemelor mari i complexe.
UML este un limbaj pentru specificarea, construirea, vizualizarea i documentarea unui sistem software complex.
Un programator anonim a spus 1 bitmap = 1 megaword. Din aceast afirmaie putem s tragem concluzia ct de semnificativ este utilizarea unor metode, limbaje pentru care au fost create diverse instrumente de lucru, care redau descrierea sistemului prin intermediul diferitelor notaii grafice, mult mai sugestive, i care uureaz enorm munca n echip, reducnd n acelai timp perioada pentru analiza i proiectarea sistemului. [Kobryn, 2001] Sfera de ntindere a limbajului unificat de modelare este: n primul rnd i cel mai important, UML este un limbaj care reunete conceptele utilizate de Booch, OMT i OOSE. Rezultatul este un limbaj de modelare unic, comun i n mare msur uor de folosit pentru utilizatorii acestor metode, precum i altele. n al doilea rnd, UML extinde sfera de cuprindere a ceea ce se dorete a fi fcut cu metodele existente. n al treilea rnd, UML se bazeaz pe limbaje standard de modelare i nu pe un proces standard. Aa cum sugereaz chiar numele limbajului, sprijinul oferit de limbaj vizeaz n primul rnd construirea modelelor. Acestea ar fi noiunile care in de UML, dar n afara acestora ar mai fi de adugat urmtoarele: UML este un limbaj vizual de modelare, dar care nu are pretenia de a fi un limbaj de programare vizual, el este un limbaj universal pe care dezvoltatorii l pot utiliza pentru descrierea sistemelor lor. De ce este un limbaj ? Deoarece UML utilizeaz o sintax (reprezint elementele limbajului care sunt asamblate n expresii) i o semantic (nelesurile expresiilor sintactice) pentru a descrie sistemul. Pentru descrierea sistemului dezvoltatorii folosesc anumite notaii grafice standard. Astfel, UML surprinde i descrie n limbaj natural sistemul. Ceea ce nu rezolv UML este problema schimbului de date, care poate fi rezolvat cu Microsoft Repository. Pentru programarea codului se poate utiliza unul din limbajele orientate obiect cele mai cunoscute. UML dispune la ora actual de mai multe instrumente prin intermediul crora toat munca este executat prin intermediul calculatorului. Instrumentele i interoperabilitatea dintre ele este dependent de definiia semanticii i a notaiei: UML definete un metamodel semantic, i nu un instrument de interfa, memorare, sau execuie a modelului. 5.2.2. Noiuni generale despre UML UML reprezint o arhitectur bazat pe 4 niveluri de abstractizare (figura 5.12.). Cele patru niveluri de abstractizare sunt: meta-metamodelul (reprezint infrastructura pentru o arhitectur de metamodele), metamodelul (reprezint o instan a unui meta-metamodel i definete semantica necesar pentru reprezentarea modelelor aplicaiei cu ajutorul UML), modelul (reprezint o instan a metamodelului) i obiecte utilizator (reprezint o instan a unui model, utilizat pentru descrierea unui domeniu de informaie specific).
Metamodelul UML este un model logic i nu unul fizic (de implementare) i are n componena sa trei pachete logice: Elemente de comportament (Behavioral Elements), Elemente de baz (Foundation) i Mecanisme generale (Model Management), dup cum se poate observa din figura 5.13.
i ect - 63 Analiza i proi ectarea ori entat ob
Fig. 5.12. Arhitectura metamodelului UML
Fig. 5.13. Structura pachetului UML n cadrul fiecrui pachet, elementele unui model sunt definite n urmtorii termeni:
Sintaxa abstract: este prezent n diagrama claselor UML i prezint metamodelul UML,
conceptele sale (metaclase), relaiile i constrngerile. Diagrama prezint reguli foarte bine formulate, n special cerinele legate de multiplicitatea legturilor, i cnd, sau nu, instana unui subconstructor particular trebuie s fie ordonat. Pentru fiecare metaclas, atributele sale sunt enumerate mpreun cu o scurt explicaie. n plus, numele rolurilor asocierilor conectate la metaclas sunt scrise la capetele fiecrei asocieri. Reguli foarte bine formate (reguli de corectitudine - well-formedness rules): sunt definite regulile i constrngerile impuse modelelor corecte. Semantica static a metaclaselor UML, exceptnd multiplicitatea i constrngerile, sunt definite ca un set de invariante ale unei instane a metaclasei. Semantica: specific modelele utilizate pentru structura i comportamentul obiectului, prezentat n mod normal n limba englez.
Analiza i proi ectarea ori entat ob i ect - 64
Fig. 5.14. Diagrama claselor UML, structurarea n pachete i subpachete Figura 5.14. arat dependenele ntre elementele modelului UML din diferite pachete. Modelele structurale (modele statice) accentueaz structura obiectelor ntr-un sistem, incluznd clasele lor, interfeele, atributele i relaiile. Modelele de comportament (modele dinamice) accentueaz comportamentul obiectelor ntr-un sistem, incluznd metodele, interaciunile, colaborrile i starea lor istoric. Semantica este definit ntr-o modalitate independent de limbajele de implementare. O implementare a semanticii, fr o interfa consistent i alegerile implementrii, nu garanteaz interoperabilitatea instrumentului. Alegerea modelelor i diagramelor are o profund influen asupra problemei supuse analizei i modului n care soluia corespunde problemei. Din acest motiv: Fiecare sistem complex va trebui supus unei analize din mai multe puncte de vedere. Fiecare model poate fi exprimat la diferite nivele de fidelitate. Cel mai bun model este cel legat de realitate. Un model reprezint o colecie de obiecte (Classes, Packages, Actors, Use Cases, Components i Nodes), relaii (Association, Dependencies i Generalization) i diagrame. Din punctul de vedere al unui model, UML definete diferite tipuri de diagrame grafice, al cror numr a crescut de la 9 tipuri standard, varianta UML 1.1, pn la 13 tipuri, varianta UML 2.0.
Diagrama cazurilor de utilizare (use case diagram). Diagrama claselor (class diagram). Diagrama obiectelor (object diagram). Diagrame de comportament (behaviour diagrams): diagrama de stare, numit i diagrama graficelor de stare (statechart diagram); diagrama de activitate (activity diagram); diagrame de interaciuni (interaction diagrams): diagrama secvenial (succesiune) (sequence diagram); diagrama de colaborare (collaboration diagram); Diagrame de implementare (implementation diagrams): diagrama de componente (component diagram); diagrama de aplicaie (de dezvoltare) (deployment diagram).
Aceste diagrame furnizeaz perspective multiple asupra sistemului analizat, privind analiza i/sau dezvoltarea sa. Legtura dintre modele i diagrame este ilustrat n figura 5.15.
Fig. 5.15. Modele, vederi i diagrame De ce este UML un limbaj de modelare i nu o metodologie ? Modelarea este proiectarea aplicaiilor software nainte de implementarea codului n diferite limbaje de programare. O metodologie este alctuit din dou componente: un limbaj de modelare i un proces de modelare care arat succesiunea de pai care trebuie parcuri pentru realizarea modelului. Un limbaj de modelare trebuie s includ:
Elementele modelului conceptele de modelare fundamentale i semantic. Notaia interpretarea vizual a elementelor modelului. Notaia UML este un element esenial
pentru UML care permite comunicarea ntre membrii echipei de lucru. Acceptarea notaiei este opional, dar semantica nu va fi foarte semnificativ dac nu este bine exprimat. Acceptarea notaiei este definit n cadrul fiecrui tip de diagram UML: cazuri de utilizare, clase, grafice de stare, de activitate, secvenial, de componente i de dezvoltare. Linii directoare (guidelines) utilizarea sintagmelor (expresiilor) n interiorul produsului.
Scopurile principale ale UML sunt urmtoarele:
S furnizeze utilizatorilor un limbaj de modelare vizual expresiv pentru dezvoltarea i specificarea semnificaiei modelului. Mecanisme extensibile i specializate pentru a extinde conceptele de baz. Suport pentru specificaii care sunt independente de un limbaj de programare particular i dezvoltarea proceselor. Furnizeaz o baz formal pentru nelegerea limbajului de modelare. ncurajeaz creterea vnzrilor de instrumente obiect. Suport concepte de dezvoltare de nivel superior precum componente, colaborri, frameworks i modele. Integreaz cele mai bune practici existente la ora actual. 5.2.3. Concepte UML Unul din scopurile modelrii vizuale este de a nelege arhitectura aplicaiei. Membrii echipei de lucru pot nelege aceast arhitectur a aplicaiei prin intermediul diagramelor de modelare UML. Pentru nelegerea conceptelor UML sunt utilizate trei tipuri principale de blocuri constructive: Elementele. Relaiile. Diagramele. precum i: Mecanisme extensibile: stereotipuri, constrngeri, i valori etichetate (tagged value). Conceptele cele mai utilizate sunt cele preluate de la cei trei care au contribuit la apariia limbajului de modelare UML, Booch, Rumbaugh i Jacobson. Cu toate acestea, anumite elemente constructive sunt preluate de la alte metode aparinnd altor specialiti din domeniul analizei i proiectrii sistemelor: Shlaer & Mellor, Martin & Odell, Wirfs & Brock, Fusion, Meyer, Harel, Gamma etc.
Fig. 5.16. Contribuii la dezvoltarea UML Elementele UML

Elementul este constituentul atomic al unui model. ntr-un metamodel elementul reprezint cea mai
nalt metaclas n ierarhia metaclaselor, fiind o clas abstract. Exist dou metasubclase: Element de Model (ModelElement) i Element de Prezentare (PresentationElement), care la rndul lor sunt construcii abstracte. Elementele UML pot fi grupate astfel: structurale (statice), comportamentale (dinamice), de grupare i suplimentare. Un tip special de ModelElement este clasificatorul, care este un element ce descrie caracteristicile structurale i de comportament, dintre care amintim: clasa, interfaa, tipuri de date, nodul, componenta, semnalul, actorul, caz de utilizare i subsistem.
Elementele structurale Elementele structurale reprezint prile statice ale unui model, reprezentnd elemente conceptuale sau fizice i care sunt componente ale pachetelor Elemente de baz (clasa, interfaa, nodul, componenta, tipuri de date) i o parte din Elemente de comportament (colaborarea i caz de
utilizare).
n continuare se vor prezenta acele aspecte ale elementelor structurale care nu au fost descrise n prezentarea conceptelor de baz ale tehnologiei orientate obiect. O clas reprezint o descriere a unui set de obiecte care au n comun aceleai atribute, operaii, metode, relaii i semantici. Scopul unei clase este de a declara o colecie de metode, operaii i atribute care descriu complet structura i comportamentul obiectelor. Clasele pot fi considerate drept obiecte, dar ele sunt meta-obiecte, nu obiecte ale lumii reale. Obiectele care descriu clasele au propriile lor caracteristici, deci au clase proprii numite metaclase. Fiecare obiect instaniat dintr-o clas conine propriul set de valori corespunztor atributelor i suport operaiile declarate n descrierea complet a clasei. Fiecare clas trebuie s aib un nume care s o disting de celelalte clase. O clas activ este o clas ale crei obiecte au propriile fire de control (posed unul sau mai multe procese sau cursuri ale prelucrrii i care poate iniia o activitate de control) i al cror comportament este concurent cu alte elemente. n caz contrar, avem de-a face cu o clas pasiv. UML suport urmtoarele tipuri de clase:
Clas abstract este acea clas care nu poate avea instane directe. Clas rdcin este acea clas care nu are prini (strmoi), deci nu poate fi o subclas a altor
clase.
Clas frunz este acea clas care nu poate avea are copii (descendeni), deci nici o alt clas nu
poate fi o subclas a clasei. O clas poate implementa un set de interfee pentru a specifica setul de operaii pe care le furnizeaz mediului su. O subclas poate aduga noi atribute i/sau operaii fa de caracteristicile claselor ascendente, caz n care spunem c avem de-a face cu o extensie a clasei. De asemenea, o subclas poate restrnge atributele claselor ascendente, caz n care spunem c avem de-a face cu o restricie a clase, limitndu-le tipul la un singur subtip al tipului respectiv. Fiecare generalizare trebuie s se fac
dup o singur proprietate. Dac o clas poate fi rafinat dup mai multe dimensiuni distincte i independente se realizeaz generalizri multiple. O interfa reprezint un set de operaii, care mpreun definesc un serviciu oferit de un clasificator (clas sau component) i care descrie comportamentul vizibil extern al acestuia, integral sau parial. Un clasificator poate oferi mai multe servicii, ceea ce nseamn c el poate realiza mai multe interfee i mai muli clasificatori pot realiza aceeai interfa. Un nod este un obiect fizic run-time (exist n timpul execuiei) i care reprezint o resurs de calcul avnd n general memorie i mai multe procese capabile de prelucrare. O component reprezint o parte fizic a unui sistem, care implementeaz pachete i permite realizarea unui set de interfee; ea reprezint o implementare a unui sistem, incluznd cod software (surse, binare, sau executabile) sau echivalente precum script-uri sau fiiere de comand. Un tip de date reprezint un tip ale crui valori nu au identitate. Tipurile de date includ tipuri primitive (precum integer sau string), tipuri enumerate etc. O colaborare definete o interaciune i descrie modul n care diferii clasificatori i alte elemente (asocierile clasificatorilor) se utilizeaz la realizarea unui anumit comportament particular (un task particular); o clas poate participa la mai multe colaborri, iar scopul unei colaborri este de a specifica modalitatea n care o operaie sau un clasificator, cum ar fi un caz de utilizare, este realizat de un set de clasificatori i asocieri. Un caz de utilizare este folosit pentru a defini comportamentul unui sistem fr a dezvlui structura intern a entitii. Fiecare caz de utilizare specific descrierea unei succesiuni de aciuni pe care sistemul le poate realiza, interacionnd cu actorii sistemului, pentru a obine un rezultat observabil de un anumit actor. n afara celor 7 elemente structurale de baz, UML mai utilizeaz i alte elemente structurale, printre care pot fi menionate:
Actor, este un element definit n subpachetul Use Cases al pachetul Behavioral Elements. Un actor definete un set coerent al rolurilor pe care utilizatorii unei entiti (sistem, subsistem, clas) l poate executa atunci cnd interacioneaz cu entitatea respectiv. Instana unui actor este un utilizator specific care interacioneaz cu entitatea, iar n cazul n care entitatea este un sistem actorii reprezint att utilizatori umani ct i alte sisteme. Actorii pot face parte din interiorul sau din afara entitii cu care interacioneaz; ei pot comunica cu un set al cazurilor de utilizare, pot avea un set de interfee i pot avea relaii de generalizare cu ali actori. Un actor este un obiect care opereaz asupra altor obiecte dar asupra cruia nu poate opera alt obiect (de regul, obiect activ). Semnal, este un element definit n subpachetul Common Behavior al pachetului Behavioral Elements. Printre caracteristicile de baz ale unui semnal se impun: un semnal este o specificare a unui stimul asincron comunicat ntre instane; un semnal poate fi ataat unui clasificator, ceea ce nseamn c instana clasificatorului va fi capabil s primeasc acest semnal; semnalul este un element generalizabil i este definit independent de clasele care utilizeaz semnalul. Atunci cnd un semnal este cauzat de o caracteristic de comportament specific apariiei unei erori, se spune c s-a produs o excepie. Elemente comportamentale reprezint prile dinamice ale modelelor UML i ele sunt definite n
pachetul Behavioral Elements (acest pachet specific comportamentul dinamic al modelelor). Principalele elemente comportamentale sunt: interaciunea i maina de stri.
O interaciune este un comportament care conine un set de mesaje schimbat ntre un set de obiecte ntr-un anumit context, definit de ClassifierRoles, pentru a ndeplini un anumit obiectiv. Caracteristicile unei interaciuni sunt definite n subpachetul Collaborations, iar n realizarea unei interaciuni sunt implicate i alte elemente:
Mesajul, este definit n subpachetul Collaborations i definete o comunicare particular ntre
instanele specificate de o interaciune. El specific rolurile instanelor expeditorului i receptorului, n aa fel nct rolul asocierii va specifica legtura de comunicare. Mesajul este ataat unei aciuni, specificnd instruciunea care, atunci cnd este executat, determin comunicarea specificat. Aciunea, este o metaclas abstract definit n subpachetul Common Behavior, fiind o specificare a unei instruciuni executabile care formeaz o abstractizare a unei proceduri de calcul, avnd drept rezultat o modificare a strii modelului, care poate fi realizat prin trimiterea unui mesaj ctre un obiect sau prin modificarea unei legturi. Legtura, definit n subpachetul Common Behavior, reprezint o instan a unei relaii de asociere i definete o conexiune ntre instane. O main de stare reprezint o specificaie care descrie succesiunile de stri ale unui obiect sau interaciuni n timpul ciclului de via, ca rspuns la evenimente, mpreun cu rspunsurile sale la acele evenimente. Comportamentul este modelat ca o parcurgere a unui grafic al nodurilor de stare interconectate la una sau mai multe arcuri de tranziii asociate unor stri ale instanelor de evenimente. n timpul acestei parcurgeri, maina de stare execut o serie de aciuni asociate diferitelor elemente ale mainii de stare. Caracteristicile i modul de comportare a unei maini de stri este definit n subpachetul State Machines. La rndul ei, o main de stri implic un numr de alte elemente:
Starea este o metaclas abstract care modeleaz o situaie n timp ce alt condiie invariant o
susine. Totodat poate reprezenta o condiie a unui model dinamic, precum procesul realizrii unei activiti. n timpul execuiei unui eveniment o stare poate fi activ (este o intrare ca rezultat a unei tranziii) sau inactiv (exist ca rezultat al unei tranziii). Tranziia este o relaie direct ntre un nod de stare surs i un nod de stare destinaie. Ea poate fi parte a unei tranziii compuse, care duce maina de stare dintr-o stare de configurare n alta, ca rezultat al unui eveniment particular. Evenimentul este generat ca rezultat al unei aciuni fie din interiorul sistemului sau din mediul nconjurtor sistemului. Aciunea (ca rspuns la o tranziie). Cele dou elemente (interaciunea i maina de stare) sunt conectate la diferite elemente structurale: clase, colaborri, obiecte.
Elementele de grupare reprezint prile
organizaionale
ale modelelor UML, definite n
pachetul Model Management, care cuprinde urmtoarele elemente:

Pachetul (package) este un mecanism cu scop general pentru organizarea elementelor n grupuri de elemente structurale, elemente comportamentale sau chiar alte elemente de grupare. Un pachet reprezint de fapt o grupare a elementelor unui model. Modelul reprezint o abstractizare a unui sistem fizic, cu un anumit scop, specificnd sistemul fizic din diferite puncte de vedere ale abstractizrii, el reprezentnd de fapt o descriere complet a unui sistem dintr-o anumit perspectiv (particular). Scopul avut n vedere va determina elementele care vor fi considerate (incluse n model) semnificative i nesemnificative pentru model. Un model va conine o ierarhie de elemente care mpreun descriu sistemul fizic. De asemenea, va conine i un set de elemente care reprezint mediul nconjurtor al sistemului, cum ar fi actorii mpreun cu interaciunile lor, precum relaiile de dependen, generalizri i constrngeri. Subsistemul este o grupare a elementelor de model care reprezint un element comportamental al unui sistem fizic. Un subsistem ofer interfee i are operaii proprii. Analiza i proiectarea orientat obiect 6969
Elemente suplimentare, printre care enumerm: Note pentru formularea constrngerilor i altor comentarii. Comentariu este o notaie ataat unui element sau unui set de elemente ale modelului. Cerine pentru specificarea comportamentului dorit din perspectiva exterioar modelului.
Relaii UML O relaie reprezint o conexiune ntre elementele modelului, fiind un termen convenional (abstract), fr specificaii semantice. Relaiile suportate de UML sunt de: asociere, dependen, realizare (sau de flux), i generalizare. O relaie de asociere este o relaie structural care descrie un set de legturi, o legtur fiind o conexiune ntre obiecte. Asocierea declar o conexiune ntre instanele clasificatorilor asociai, constnd din cel puin dou terminaii de asociere, fiecare specificnd un clasificator conectat i un set de proprieti care trebuie s fie realizat pentru ca fiecare relaie s fie valid (corect). De asemenea, se poate specifica rolul pe care fiecare clasificator l ndeplinete n relaia de asociere; multiplicitatea pentru fiecare capt al asocierii, care va specifica cte (numrul) instane ale clasificatorului aflat la sfritul asocierii pot fi asociate cu o singur instan a clasificatorului surs (aflat la nceputul asocierii). Unei relaii de asociere i se poate ataa i un calificator, care reprezint un atribut special care reduce multiplicitatea efectiv a relaiei de asociere, rezultnd o asociere cu calificator. n UML asocierile pot fi de trei feluri:
Asociere ordinar reprezint relaia de asociere cea mai utilizat, prin intermediul creia doi calificatori sunt conectai. Agregare de compoziie (composite aggregate) este o form puternic a agregrii. Ea presupune c o instan (un obiect) poate face parte la un moment dat numai dintr-un singur obiect compus i c obiectul compus este singurul responsabil pentru caracterul prilor sale. Dac obiectul compus este distrus, el trebuie s distrug toate prile sale componente. Agregare partajat (shared aggregate) partea poate fi inclus n mai multe agregri i proprietile sale se pot modifica n timp. Agregarea este un tip special al relaiei de asociere, reprezentnd o relaie structural ntre un ntreg i pri ale acestuia (relaie parte-ntreg), deci ea leag o clas ansamblu cu o clas component. Numai asocierile binare pot fi agregri.
O relaie de dependen este o relaie semantic ntre dou elemente prin care o modificare n unul din elemente, numit element independent, poate afecta semanticile celuilalt element, numit element dependent. O dependen este un termen convenional pentru o relaie alta dect asocierea, generalizarea, realizarea (flux), sau alte metarelaii (precum relaia ntre un clasificator i una din instanele sale). ntr-un metamodel, o dependen este o relaie direct ntre un client (sau clieni) i un furnizor (sau furnizori), stabilind dependena clientului fa de furnizor. Tipurile relaiilor de dependen suportate de UML sunt:
Abstractizarea este o relaie de dependen care leag dou elemente, sau seturi de elemente,
reprezentnd acelai concept la nivele diferite de abstractizare, sau din puncte de vedere diferite.
Legtura (binding) o conexiune ntre elementele din cadrul aceluiai model. O legtur trebuie s aib un furnizor (desemneaz elementul care nu este afectat de o modificare) i un client. Un element furnizor poate participa n mai multe relaii de legtur ctre diferii clieni. Un element client poate participa numai ntr-o singur relaie de legtur cu un furnizor. O legtur este o relaie de dependen unde furnizorul este un model i clientul reprezint instanierea modelului care ndeplinete substituirea parametrilor modelului. Utilizarea este o relaie n care un element are nevoie de un alt element (sau set de elemente) pentru implementarea sa complet. O utilizare este o relaie de dependen n care clientul necesit prezena furnizorului, de exemplu: o clas apeleaz o operaie a unei alte clase (<<call>>); o metod avnd un argument al altei clase (<<create>>); o metod dintr-o clas instaniaz alt clas (<<instantiate>>). Permisiunea este o relaie care acord unui element (client) dreptul s acceseze alte elemente (furnizori). Clientul primete permisiunea s fac referire la coninutul furnizorului. Furnizorul trebuie s fie o asociere sau un clasificator.
O relaie de realizare este o relaie semantic ntre clasificatori, n care un clasificator specific un contract a crui realizare e garantat de un alt clasificator. Este o relaie ntre dou versiuni ale unui obiect sau ntre un obiect i o copie a sa. Exemple de relaii de realizare: ntre interfeele i clasele sau componentele care le realizeaz, ntre cazurile de utilizare i colaborrile prin care acestea se realizeaz. O relaie de generalizare este o relaie de clasificare ntre mai multe elemente generale (un element generalizabil este un element care poate participa ntr-o relaie de generalizare i / sau de specializare) i mai multe elemente specifice. O generalizare este o relaie de generalizare-specializare n care obiectele elementului specializat (fiu sau copil) partajeaz structura i comportamentul obiectelor elementului generalizat (printe). Generalizarea ntre clase implic substituirea. Astfel, dac o clas este specificat ca root, ea nu poate fi o subclas a altei clase (nu poate avea strmoi). n mod similar, dac ea este specificat drept clas frunz (leaf), nici o alt clas nu poate fi o subclas a clasei (nu poate avea descendeni). n afara acestor relaii, n UML mai sunt definite dou tipuri de relaii care sunt utilizate n conjunctur cu cazurile de utilizare (use cases):
Relaia de extindere (extend), definit n subpachetul Use Cases din pachetul Behavioral Elements, este o relaie prin care comportamentul i structura unui caz de utilizare poate fi mbuntit cu comportamentul i structura unui alt caz de utilizare. Relaia are loc numai dac condiia care o nsoete este ndeplinit. Relaia de includere (include), definit n subpachetul Use Cases din pachetul Behavioral Elements, semnific faptul c un caz de utilizare conine comportament definit n alt caz de utilizare. Relaia de includere este o relaie ntre dou cazuri de utilizare.
5.2.4. Diagramele UML nainte de a trece la prezentarea diagramelor utilizate de UML, trebuie specificat c exist trei perspective care trebuie utilizate n desemnarea diagramelor (sau a oricrui model) [Cook&Daniels, 1994]:
Conceptual: n acest caz se utilizeaz o diagram care reprezint conceptele din domeniul sistemului supus analizei. Aceste concepte vor avea legtur cu clasele pe care le implementeaz, dar nu este o reprezentare direct. Modelul este proiectat fr a ine seama de software-ul care l va implementa i este n general independent de limbaj. Specificaia: n acest moment atenia este ndreptat ctre software, dar de fapt ctre interfeele software-ului i nu ctre implementarea propriu zis. Dezvoltarea orientat obiect pune un mare accent pe diferena ntre interfa (tip) i implementare (clas). Tipurile reprezint o interfa care
poate avea mai multe implementri datorit mediului de implementare, caracteristicilor de performan etc. Implementarea: n momentul implementrii se utilizeaz clasele. Dup cum s-a artat n versiunii UML 2.0 exist 13 diagrame (n loc de 9), mprite n 3 categorii: 1. Diagrame de structur: descriu structura static a aplicaiei. 2. Diagrame de comportament: descriu aspecte diferite ale comportamentului dinamic. 3. Diagrame de interaciune: reprezint un subset al diagramelor de comportament care accentueaz interaciunile dintre obiecte.
Diagrame 1. Diagrama de activitate 2. Diagrama claselor 3. Diagrama de comunicaie Descriere Ilustreaz procesele de afaceri, incluznd fluxul de date. Arat o colecie de elemente ale modelului static, precum clasele i tipul lor. Arat instane ale claselor, relaiile de interaciune dintre ele, i fluxul mesajelor dintre ele. Diagrama se concentreaz pe organizarea structural a obiectelor care trimit i primesc mesaje. La vechile versiuni era denumit diagrama de colaborare. Ilustreaz componentele care compun ntreprinderea, sistemul, sau aplicaia. Ilustreaz structura intern a unui clasificator (clas, component, caz de utilizare), inclusiv punctele de interaciune ale clasificatorului cu alte pri ale sistemului. Arat execuia arhitecturii de sistem. Aceasta include noduri, componente hardware sau medii de execuie software, precum i produse middleware. O variant a diagramei de activitate care face o privire de ansamblu a fluxului de control n interiorul sistemului sau procesului de afaceri. Fiecare nod / activitate din interiorul diagramei poate reprezenta alt diagram de interaciune. Ilustreaz obiectele i relaiile lor la un anumit moment de timp, n mod normal un caz special fie a diagramei claselor sau a diagramei de comunicaie. Arat cum elementele de model sunt organizate n pachete, precum i dependenele dintre pachete. Modeleaz logica secvenial, n fapt ordonarea n timp a mesajelor dintre clasificatori. Descrie strile unui obiect, precum i tranziiile dintre stri. Ilustreaz modificarea n stare sau condiie a instanei unui clasificator sau rol n timp. Este utilizat pentru a arta modificarea strii unui obiect n timp ca rspuns la evenimente externe. Arat cazurile de utilizare, actorii, i relaiile dintre ele.
4. Diagrama de componente 5. Diagrama de structur compus
6. Diagrama de aplicaie
7. Diagrama de concluzionare a interaciunilor (interaction overview)
8. Diagrama de obiecte
9. Diagrama de pachete 10. Diagrama secvenial 11. Diagrama mainilor de stare 12. Diagrama de sincronizare (timing)
13. Diagrama cazurilor de utilizare
O diagram poate conine colecii ale urmtoarelor tipuri de obiecte: actori (diagrama cazurilor de utilizare), clase (diagrama claselor), componente (diagrama componentelor sau de aplicaie), noduri (diagrama de aplicaie), pachete (diagrama claselor sau pachetelor), cazuri de utilizare (diagrama cazurilor de utilizare), stri (diagrama de activitate sau de stare), obiecte (diagrama obiectelor, de colaborare, secvenial, componentelor, de aplicaie, sau de activitate), semnale (diagrama de activitate), asocieri (diagrama claselor, cazurilor de utilizare, sau obiectelor), generalizri (diagrama claselor, pachetelor, sau cazurilor de utilizare), dependene (diagrama claselor, cazurilor de utilizare, componentelor, sau de aplicaie), tranziii (diagrama de activitate sau de stare), interaciuni (diagrama de colaborri), mesaje (diagrama secvenial) etc. Diagrama Claselor (Class Diagram) Diagrama claselor reprezint tehnica central de modelare pe care se bazeaz toate modelele orientate obiect. Diagrama claselor este un grafic al clasificatorilor conectai prin relaii statice care exist ntre clasificatori precum asocierea, compoziia (agregarea de compoziie), delegaia (permisiunea) i generalizarea. O astfel de diagram mai poate conine interfee, pachete, relaii, i chiar instane, precum obiecte i legturi. Un nume mai corect pentru aceast diagram ar fi diagrama de structur static.
Obiectivul principal al acestei diagrame este s defineasc clasele de baz mpreun cu caracteristicile utilizate n alte diagrame dinamice.
Diagrama claselor este utilizat pentru: Modelarea clasele de baz (caracteristicile artate n alte diagrame dinamice). Modelarea colaborrilor (specificarea claselor i a relaiilor acestora). Modelarea schemei logice a bazei de date. Modelarea vocabularului sistemului (specificarea abstraciilor i a responsabilitilor acestora). Diagrama claselor poate fi implementat ca o clasa actual, care este utilizat n limbajele suportate de clas, i care cuprinde: clase, interfee, note i legarea notelor, text, relaii de dependen, de generalizare, de asociere, de realizare i de agregare (agregarea de compoziie), colaborri. Noiunile de clas, interfa, colaborare i relaiile utilizate au fost explicate n subcapitolele precedente. Pentru nelegerea corect a acestei diagrame mai este necesar explicarea altor concepte utilizate n proiectarea ei. Ceea ce trebuie subliniat este faptul c un clasificator declar o colecie de caracteristici, precum: atribute, metode, i operaii. Numele fiecrui clasificator este unic i reprezint o metaclas abstract. Un atribut reprezint un nume din interiorul unui clasificator i care descrie un domeniu de valori pe care le poate lua instanele clasificatorului, putnd avea o valoare iniial. De asemenea, un atribut poate avea una din urmtoarele proprieti, care se refer la posibilitatea de modificare a valorii, dup ce obiectul a fost creat:
changeable (modificabil) n acest caz nu este impus nici o restricie asupra valorii atributului; addOnly - valabil numai pentru atributele cu multiplicitate mai mare dect unu; o valoarea odat
adugat nu mai poate fi tears sau modificat; frozen - valoarea atributului nu poate fi modificat dup iniializarea obiectului.
O operaie este un serviciu care poate fi cerut de ctre un obiect pentru a efectua un comportament; ea este o semntur, care descrie parametrii actuali care sunt posibili (inclusiv posibile valori returnate). O operaie poate fi polimorfic, ceea ce nseamn c, ntr-o ierarhie de clase, pot fi specificate operaii cu aceeai semntur la nivele diferite n ierarhie dar cu implementri diferite. O operaie poate avea una din urmtoarele proprieti (se refer la simultaneitatea apelurilor concurente ctre aceeai clas pasiv este o instan a unui clasificator cu atributul isActive = False):
isQuery se refer i la o metod (operaia i metoda reprezint caracteristici dinamice ale unui element al modelului) i arat dac o execuie a unei operaii, sau a unei metode, schimb sau nu starea sistemului. Dac are valoarea True starea sistemului rmne neschimbat; sequential (secvenial) apelurile trebuie coordonate n aa fel nct numai unul poate apela o instan (pe orice operaie secvenial), la un moment dat; n caz contrar semantica i integritatea sistemului nu pot fi garantate; guarded (prudent) apeluri multiple se pot produce simultan ctre o instan, dar numai un apel este permis s nceap; celelalte operaii sunt blocate pn cnd realizarea primei operaii este terminat complet. O operaie de acest tip este utilizat pentru secvenierea apelurilor n cazul fluxurilor multiple ale controlului; concurrent (concurent) apeluri multiple se pot produce simultan ctre o instan, fiecare dintre ele putnd fi realizate n paralel.
O operaie poate avea i parametri care pot fi utilizai n specificarea operaiilor, semnalelor, mesajelor, evenimentelor etc., i fiecare parametru include un nume, tip i direcia comunicrii. Pentru fiecare parametru al unei operaii se poate specifica direcia astfel:
in reprezint un parametru de intrare care nu poate fi modificat; out reprezint un parametru de ieire, care poate fi modificat pentru a comunica informaii ctre
alte elemente; inout reprezint un parametru de intrare care poate fi modificat; return reprezint o valoare returnat unui apel. O metod reprezint o implementare a unei operaii, i specific algoritmul sau procedura care produce efectele unei operaii. Unul dintre cele mai importante detalii care poate fi specificat pentru atributele i operaiile unui clasificator este vizibilitatea acestora. Vizibilitatea unei caracteristici (atribut sau operaie) specific cnd aceasta poate fi, sau nu, utilizat de un alt clasificator. n UML se pot specifica urmtoarele nivele de vizibilitate:
public (public) orice alt clasificator, care are vizibilitate, poate utiliza atributul sau operaia
respectiv;
protected (protejat) orice descendent al clasificatorului poate utiliza atributul sau operaia; private (privat) numai clasificatorul nsui poate utiliza atributul sau operaia.
Un alt detaliu care poate fi specificat drept o caracteristic (atribut sau operaie) a unui clasificator este scopul (scope), care poate fi:
instance (instan) fiecare instan a clasificatorului conine propria valoare a caracteristicii; classifier (clasificator) exist o singur valoare pentru toate instanele unui clasificator. Multiplicitatea clasei specific numrul de instane ale clasei. Multiplicitatea se aplic i la nivel de
atribut. Pentru relaiile de dependen (abstractizarea, legtura, utilizarea i permisiunea) ntre clasele i obiectele din diagrama claselor se pot defini urmtoarele stereotipuri:
Relaia de abstractizare: <<derive>> - specific o relaie de derivare de-a lungul elementelor unui model care sunt n
mod normal de acelai tip; se poate utiliza cnd se dorete modelarea relaiei ntre dou atribute sau dou asocieri, dintre care una este concret iar cealalt este conceptual; <<realize>> - specific o relaie de realizare ntre un element (sau elemente) numit furnizor (respectiv furnizori) i un alt element (sau elemente) numit client (respectiv clieni) pe care le implementeaz;
<<refine>> - specific o relaie de rafinare ntre elementele modelului la nivele semantice
diferite, precum analiza i proiectarea (sursa este la un grad mai fin de abstractizare dect inta); <<trace>> - reprezint o relaie de urmrire ntre elementele modelului, sau seturi de elemente, care reprezint acelai concept n modele diferite; Relaia de permisiune: <<access>> - este un tip de relaie de dependen ntre dou relaii de asociere sau doi clasificatori, indicnd c prile publice ale destinaiei sunt accesibile sursei pachetului; <<friend>> - este un tip de relaie de dependen a crei surs este un element, precum o operaie, clas, sau pachet i a crui destinaie este un element dintr-un pachet diferit, precum o operaie, o clas, sau pachet; acord accesul sursei la destinaie indiferent de modul de declarare a vizibilitii; <<import>> - este un tip de relaie de dependen ntre dou asocieri, sau doi clasificatori, indicnd c prile publice ale destinaiei sunt adugate sursei. Relaia de utilizare: <<call>> - sursa este o operaie i destinaia este tot o operaie; <<create>> - clasificatorul client creeaz instane ale clasificatorului furnizor; <<instantiate>> - operaiile pentru client creeaz instane ale furnizorului; <<send>> - sursa este o operaie i destinaia este un semnal (sursa trimite un semnal).
Fig. 5.17. Diagrama claselor Pentru relaia de asociere mai pot fi specificate:
Direcia de navigare de la obiectele de un tip la obiecte de alt tip. Vizibilitatea asocierii specific vizibilitatea unui sfrit al asocierii din punctul de vedere al
clasificatorului de la cellalt capt al asocierii; valorile posibile sunt: public, protected i private.
Calificator reprezint un atribut al asocierii ale crui valori partiioneaz setul de obiecte legate la un obiect printr-o asociere; dac nu are nici o valoare relaia de asociere nu este calificat. Specificator de interfa - pentru limitarea interfeei la contextul asocierii.
De asemenea, UML permite definirea de:

Clase de asocieri reprezint o asociere care este de asemenea o clas, ea nu poate exista n afara asocierilor care o determin. Constrngeri care este o condiie semantic sau o restricie exprimat n text prin intermediul unui limbaj natural. Unele constrngeri sunt definite de UML, altele pot fi definite de utilizator. Constrngerea este o afirmare i nu un mecanism executabil. Ea indic o restricie care trebuie s fie impus pentru descrierea corect a unui sistem. Constrngerile pot fi aplicate att relaiei de asociere ct i atributelor unei clase. Interfee. O interfa este o colecie de operaii utilizate pentru a specifica un serviciu al unei clase. Interfaa poate participa la relaii de dependen, de asociere, de generalizare i de realizare.
Diagrama Obiectelor (Object Diagram) Diagrama obiectelor evideniaz un set de obiecte i relaiile cu alte obiecte la un moment dat i poate fi considerat un caz special al diagramelor claselor sau al diagramei de colaborri, fiind de fapt o instan a unei diagrame de clase, ea fiind un instantaneu al unei stri al unui sistem la un moment dat. Ea conine: obiecte, legturi, eventual note i constrngeri. Aceast diagram este utilizat pentru vizualizarea, specificarea, construirea i documentarea structurii obiectelor. Modelarea structurii obiectelor presupune: Identificarea mecanismului de modelat (o anumit funcie sau comportamentul unei pri a sistemului). Pentru fiecare mecanism, se identific clasele, interfeele i alte elemente care particip la aceast colaborare. Se consider un scenariu prin acest mecanism; se determin fiecare obiect care particip la mecanism. Selectarea obiectelor care au responsabiliti de nivel nalt pentru fluxul de lucrri (workflow). Identificarea precondiiilor strilor iniiale i postcondiiilor strilor finale. Specificarea activitilor i aciunilor ncepnd cu starea iniial. Evidenierea tranzaciilor care conecteaz aceste activiti i aciuni. Eventual, evidenierea obiectelor importante implicate n fluxul de lucrri, cu evidenierea schimbrii valorilor. Modelarea operaiilor obiectelor presupune: Colectarea abstraciilor implicate n operaii (parametri, atribute ale claselor). Identificarea precondiiilor strii iniiale i postcondiiilor strii finale. Specificarea activitilor i aciunilor ncepnd cu starea iniial. Folosirea ramificrii dac este necesar. Folosirea bifurcrii i reunirii pentru specificarea fluxurilor de control paralele. Diagrama cazurilor de utilizare (Use Case Diagram) Aceast diagram este utilizat n faza de analiz a sistemului i a cerinelor utilizatorului i arat actorii (utilizator sistem sau sistem extern) i cazurile de utilizare ale sistemului mpreun cu relaiile lor. Cazurile de utilizare reprezint funcionalitatea unui sistem sau a unui clasificator, precum un subsistem sau o clas. Prin utilizarea acestei diagrame, utilizatorii i dezvoltatorii pot uor aduga i modifica cerinele utilizatorului.
Diagrama cazurilor de utilizare este un graf al actorilor, un set al cazurilor de utilizare, posibil unele interfee, i relaiile dintre aceste elemente. Relaiile sunt de asociere ntre actori i cazurile de utilizare, generalizri ntre actori i generalizri, extensii, i includeri ntre cazuri de utilizare. Cazurile de utilizare pot fi opional incluse ntr-un dreptunghi care va reprezenta grania (interfaa) sistemului coninut. Diagrama cazurilor de utilizare se folosete pentru modelarea aspectelor dinamice ale sistemului i anume pentru modelarea comportamentului unui sistem, unui subsistem sau unei clase. O astfel de diagram conine: cazuri de utilizare, actori, relaii de dependen, de generalizare i de asociere i se utilizeaz pentru modelarea contextului sistemului (specificarea actorilor i nelegerea rolului lor) i pentru modelarea cerinelor sistemului (CE trebuie s fac sistemul, i nu CUM).
Modelarea contextului sistemului presupune:
Identificarea actorilor. Organizarea actorilor ntr-o ierarhie de generalizare / specializare. Popularea diagramei cu actorii identificai i specificarea cilor de comunicare ntre fiecare actor i cazurile de utilizare ale sistemului.
Fig. 5.18. Diagrama cazurilor de utilizare

Modelarea cerinelor sistemului presupune:
Stabilirea contextului sistemului prin identificarea actorilor. Stabilirea pentru fiecare actor a comportamentului cerut sau ateptat din partea sistemului. Specificarea cazurilor de utilizare pe baza comportamentelor comune. Identificarea de noi cazuri de utilizare care sunt utilizate de altele. Modelarea cazurilor de utilizare, a actorilor i a relaiilor ntre ei ntr-o diagram a cazurilor de utilizare. O diagram a cazurilor de utilizare bine structurat este acea diagram care: Este centrat pe comunicarea unui aspect al viziunii statice a cazurilor de utilizare ale sistemului. Conine numai acele cazuri de utilizare i actori care sunt eseniali pentru nelegerea aspectului analizat. Prevede detalii consistente cu nivelul de abstractizare (numai ceea ce este esenial pentru nelegere).
Diagramele de Interaciuni (Interaction Diagrams) Diagrama de interaciuni reprezint un termen generic care este aplicat mai multor tipuri de diagrame care subliniaz interaciunea dintre obiecte. Diagramele de interaciuni sunt utilizate n cazul n care se dorete reflectarea comportamentului mai multor obiecte dintr-un singur caz de utilizare. n funcie de criteriul care se are n vedere, aceste diagrame sunt de dou tipuri:
Diagrama secvenial care evideniaz ordonarea n timp (secvenialitatea) a mesajelor. Diagrama de colaborare evideniaz organizarea structural a obiectelor care trimit i primesc
mesaje (arat relaiile dintre instane). Diagramele de interaciune conin: obiecte, legturi, mesaje i eventual constrngeri. Diagrama secvenial (Sequence Diagram) Arat fluxul dinamic al mesajelor diferitelor obiecte din sistem. Obiectivul principal al acestei diagrame este acela de a exprima fluxul de mesaje al obiectelor n timp secvenial. Diagrama secvenial arat interaciunea obiectelor aranjate n timp secvenial. n particular, ea arat obiectele care particip la o interaciune i succesiunea mesajelor care sunt schimbate. O diagram secvenial poate exista ntr-o form generic (descrie toate scenariile posibile) i ntr-o form de exemplu (descrie un scenariu actual). Modelarea fluxului controlului prin ordonarea n timp a mesajelor presupune: Stabilirea contextului interaciunii (sistem, subsistem, operaie, sau clas, sau un scenariu al unui caz de utilizare sau colaborare). Identificarea obiectelor care au un rol n aciune. Stabilirea pentru fiecare obiect a faptului dac persist prin ntreaga interaciune; pentru obiectele create i distruse n timpul interaciunii trebuie s se indice explicit, prin mesaj, acest lucru. Pentru fiecare mesaj ncepnd cu primul (care iniiaz aciunea) i continund cu celelalte n ordinea succesiunii, se prezint proprietile (parametrii). Eventual, timpul i spaiul cerut, pentru fiecare mesaj. Eventual, precondiii sau postcondiii pentru fiecare mesaj.
Fig. 5.19. Diagrama secvenial

Pentru a evidenia fluxul complet al controlului se pot utiliza mai multe diagrame secveniale. Diagrama secvenial are dou dimensiuni: una vertical, care reprezint timpul i una orizontal, care reprezint diferite obiecte. Diagrama de colaborare (Collaboration Diagram) La fel ca i diagrama secvenial, diagrama de colaborare arat caracteristica dinamic a sistemului. Amndou diagramele sunt identice, n ceea ce privete informaia intern a diagramei, dar diagrama de colaborare pune un accent mai mare pe colaborarea dintre obiectele sistemului dect pe succesiunea n timp, specific diagramei secveniale. Deci n funcie de obiectivul urmrit, se va alege una din urmtoarele diagrame: secvenial sau de colaborare. Diagrama de colaborare arat interaciunile din interiorul structurii unui model, utiliznd fie clasificatori i asocieri sau instane i legturi. O diagram de colaborare prezint o colaborare, care conine un set de roluri ale obiectelor, sau poate prezenta o interaciune, care definete un set de mesaje specifice ei.
Fig. 5.20. Diagrama de colaborare Modelarea controlului prin organizare presupune: Stabilirea contextului interaciunii (sistem, subsistem, operaie, sau clas, sau un scenariu al unui caz de utilizare sau colaborare). Identificarea obiectelor care joac rol n aciune. Stabilirea proprietilor iniiale pentru fiecare obiect; dac starea sau rolul unui obiect se schimb semnificativ n timpul interaciunii, se plaseaz un obiect duplicat n diagram care se actualizeaz cu noile valori i se conecteaz printr-un anumit mesaj. Specificarea legturilor ntre obiecte prin care pot trece mesajele: legturile asocierii sau alte legturi (global, local). Se ncepe cu mesajul care iniiaz interaciunea i se ataeaz fiecare mesaj subsecvent conform legturilor ntre obiecte. Eventual, timpul i spaiul cerut, pentru fiecare mesaj. Eventual, precondiii sau postcondiii pentru fiecare mesaj. Diagrama de Stare Diagrama de stare este una din diagramele prin intermediul crora se evideniaz realizarea cazurilor de utilizare. Este folosit n situaia n care se dorete modelarea unui obiect care este utilizat n mai multe cazuri de utilizare. Se folosete pentru modelarea comportamentului unei interfee, unei clase sau unei colaborri i evideniaz comportamentul orientat-eveniment al unui obiect. Arat starea intern i modificarea strilor obiectelor clasei specificate, fiecare stare posibil a obiectului putnd fi exprimat cu ajutorul acestei diagrame.
O diagram de stare este un graf care reprezint o main de stri artnd fluxul controlului de la o stare la alta i va conine: stri, maini de stare, tranziii. Diagrama de stare se utilizeaz pentru modelarea unui anumit aspect dinamic al sistemului n contextul sistemului ca ntreg, unui subsistem sau unei clase. Se poate folosi pentru modelarea unui scenariu din diagrama cazurilor de utilizare. O main de stri este un comportament care arat succesiunea de stri prin care trece un obiect pe durata sa de via ca rspuns la evenimente, precum i rspunsurile la aceste evenimente. n mod normal, aceast diagram este utilizat pentru descrierea comportamentului claselor, dar poate de asemenea s descrie i comportamentul altor entiti precum: cazuri de utilizare, actori, subsisteme, operaii sau metode. Diagrama de stare se folosete pentru modelarea obiectelor reactive i presupune: Selectarea contextului (clas, caz de utilizare, sistem). Selectarea strilor iniiale ale obiectelor. Ordonarea parial a strilor stabile n durata de via a obiectelor. Decide evenimentele care pot declana o tranziie de la o stare la alta. Ataeaz aciuni la aceste tranziii i/sau la aceste stri. Verific dac toate strile pot fi atinse printr-o combinaie de evenimente. Verific secvenele de evenimente ateptate i rspunsurile lor.
Fig. 5.21. Diagrama de stare Diagrama de Activitate (Activity Diagram) Cu ajutorul acestei diagrame este exprimat tranziia activitilor. Este utilizat n special atunci cnd este necesar evidenierea legturii fiecrui serviciu sau a mai multor procese paralele. Diagrama de activitate este o diagram de tip flowchart (organigram) care evideniaz fluxul controlului de la o activitate la alta. O activitate rezult dintr-o anumit aciune (apelul altei operaii, trimiterea unui semnal, crearea sau distrugerea unui obiect) sau evaluarea unei expresii care schimb starea sistemului sau ntoarce o valoare. Diagrama de activitate este o variant a unei maini de stri n care strile reprezint performana aciunilor sau subactivitilor. Diagrama de activitate conine: stri ale activitilor i stri ale aciunilor, tranziii, obiecte. Strile activitilor pot fi descompuse i necesit un interval de timp pentru a fi ndeplinite, comparativ cu strile aciunilor care necesit timp de execuie nesemnificativ i nu se pot descompune. Pentru
obiectele implicate n fluxul controlului se poate evidenia rolul, starea i schimbarea valorilor atributelor.
Fig. 5.22. Diagrama de activitate Diagrama de activitate poate fi utilizat pentru: Modelarea workflow (activiti aa cum sunt vzute de actorii care colaboreaz cu sistemul). Aceast modelare presupune: selectarea obiectelor care au responsabiliti de nivel nalt pentru workflow; identificarea precondiiilor strilor iniiale i postcondiiilor strilor finale; specificarea activitilor i aciunilor ncepnd cu starea iniial; evidenierea tranziiilor care conecteaz aceste activiti i aciuni; eventual, evidenierea obiectelor importante implicate n workflow, cu evidenierea schimbrii valorilor. Modelarea operaiilor flowchart. Aceast modelare presupune: colectarea abstraciilor implicate n operaii (parametrii, atribute ale claselor); identificarea precondiiilor strii iniiale i postcondiiilor strii finale; specificarea activitilor i aciunilor ncepnd cu starea iniial; folosirea ramificrii dac este necesar; folosirea bifurcrii i reunirii pentru specificarea fluxurilor de control paralele. Diagramele de Implementare Diagramele de implementare arat aspecte ale implementrii, incluznd cod surs i implementarea run-time. Aceste diagrame se prezint sub dou forme:
Diagrama de componente. Diagrama de componente arat: structura codului, structura fizic a
codului bazat pe componenta de cod actual. Diagrama de componente definete care clase vor fi incluse n mai multe fiiere i care fiiere vor fi incluse n mai multe module. Totodat ea arat dependenele componentelor software, incluznd codul surs al componentelor, codul binar al componentelor, i componentele executabile. Diagrama de aplicaie. Arat structura fizic a sistemului hardware i software. Aceast diagram arat configurarea elementelor de procese run-time i componente software, procese i obiecte. Utilizarea diagramelor UML depinde de perspectiva din care este analizat sistemul software. Deoarece n dezvoltarea sistemului sunt implicate persoane cu calificri diferite (utilizatori finali, analiti, proiectani, programatori, etc.), arhitectura unui sistem poate fi descris utiliznd: viziunea cazurilor de utilizare, viziunea proiectrii, viziunea proceselor, viziunea implementrii. Pentru fiecare din aceste
viziuni se pot folosi anumite diagrame pentru evidenierea aspectelor statice i anumite diagrame pentru evidenierea aspectelor dinamice, la nivelul de detaliu cerut de fiecare caz n parte.
Fig. 5.23. Diagrama de componente
Fig. 5.24. Diagrama de aplicaie Perspectivele din care este analizat sistemul i numrul de diagrame utilizate depind de gradul de complexitate al sistemului i de natura acestuia. De exemplu, pentru modelarea unei aplicaii simple, implementabile pe un singur calculator, sunt necesare numai primele dou viziuni. [Vtui, 2000] Tabelul nr.1 Diagramele utilizate n cazul unei aplicaii simple
Aspectele statice Diagrama cazurilor de utilizare Diagrama claselor Aspectele dinamice Diagrama interaciunilor Viziunea Cazurilor de utilizare Proiectrii
Pentru sisteme complexe, implementrile n mediu distribuit, se pot utiliza toate tipurile de diagrame. Principalele mbuntiri aduse de UML fa de celelalte modele prezentate sunt urmtoarele: Separarea relaiilor structurale (asociere, generalizare, agregare) de relaiile semantice (relaii de dependen, de realizare). Simplificarea notaiilor pentru relaiile semantice utiliznd aceeai simbolizare cu etichete diferite n funcie de tipul relaiei. Extinderea noiunii de clasificatori (folosit de toate metodele analizate pentru conceptul de obiect) pentru urmtoarele concepte: interfa, tip de date, semnal, component, nod, caz de utilizare, subsistem.
Utilizarea aceluiai tip de diagram n etape diferite ale dezvoltrii sistemului. Oferirea de recomandri pentru ntocmirea diagramelor. Oferirea de criterii de verificare a corectitudinii modelrii. Pentru a uura munca de analiz i proiectare a sistemelor, precum i pentru o analiz i o planificare mai corect a procesului de dezvoltare a produsului software, diferite firme, precum Microsoft, Rational sau OMG au nceput s investeasc tot mai mult n activitile legate de metodologiile de analiz i proiectare de software. Aceste instrumente, numite instrumente de modelare vizuale orientate obiect (OOVMT Object Oriented Visual Modeling Tool), sunt utilizate pentru automatizarea elaborrii diagramelor din cadrul diferitelor metodologii utilizate n proiectarea sistemelor informatice. n momentul de fa majoritatea firmelor mari utilizeaz UML drept limbaj de modelare pentru sistemele software. Din acest motiv s-a simit necesitatea ca acesta s fie nglobat ntr-un proces unificat care s furnizeze o modalitate de elaborare riguroas a sarcinilor, innd cont de faptul c se pune un mare accent pe lucru n echip, mai ales pentru proiectele mari. Deoarece UML nu este complet (reprezint o notaie de modelare standard industrial), mai sunt utilizate i alte tehnici suplimentare, care includ: Modelarea interfeei utilizator (diagrame de control a interfeei utilizator). Modelarea datelor. Reguli de afaceri. Constrngeri etc.
Capitolul 6 Metode de proiectare a bazelor de date

Avuia cea mai important pentru o organizaie o reprezint informaia. Fr existena informaiilor o organizaie nu ar mai putea exista, iar pentru a supraveui aceste informaii trebuiesc utilizate corect, pentru a se putea obine rezultate care s conduc la alegerea celei mai bune soluii pentru prosperitatea acesteia. Pentru ca acest lucru s fie posibil de realizat, aceste informaii trebuie stocate, triate (filtrate) i analizate n funcie de necesitile aprute ntr-un anumit moment dat. Cea mai bun alegerea pentru ca aceste informaii s fie coerente, i s nu fie pierdute, sau distruse, n mod intenionat sau nu, este stocarea acestora n diverse baze de date. De reinut este citatul lui Alvin Tofler , iar informaia acumulat, o parte a avuiei naionale. Se tie c un sistem informaional cuprinde totalitatea resurselor care permit colectarea, administrarea, controlul i propagarea informaiilor ntr-o organizaie. Atunci cnd prelucrarea datelor se efectueaz prin intermediul calculatoarelor, acest sistem va cuprinde urmtoarele componente: baza de date; elementele software ale bazei de date; software de aplicaie; elementele hardware ale calculatorului; personalul care utilizeaz i dezvolt sistemul. Dintre aceste componente baza de date constituie componenta fundamental a sistemului informaional, iar dezvoltarea i utilizarea s trebuie privite din perspectiva cerinelor mai largi ale organizaiei. Prin urmare, ciclul de via al unui sistem informaional aferent unei organizaii este inerent legat de ciclul de via al sistemului de baze de date care l susine, i de asemenea, ciclul de via al aplicaiei de tip baz de date este inerent legat de ciclul de via al sistemului informaional. Ciclul de via al unui sistem informaional implic existena mai multor faze: studiu de fezabilitate; analiza cerinelor; proiectarea conceptual a datelor i operaiilor; proiectarea logic; proiectarea extern; realizarea de prototipuri; proiectarea intern i implementarea; testarea i validarea; ntreinerea (mentenana); iar etapele principale ale ciclului de via ale unei aplicaii de tip baz de date sunt [Conn]: planificarea bazei de date; definirea sistemului; colectarea i analiza cerinelor; proiectarea bazei de date; alegerea sistemului SGBD (opional); proiectarea aplicaiei; realizarea prototipului (opional); implementarea; conversia i implementarea datelor; ntreinerea operaional.
Metode de proiectare a bazelor de date 8484
Etapa de proiectare a bazei de date reprezint procesul de realizare a unui proiect pentru o baz de date, care va trata toate operaiile i obiectivele organizaiei. Calitatea unei aplicaii de baze de date depinde de proiectarea sa. Scopurile etapei de proiectare a bazei de date sunt: reprezentarea datelor i a relaiilor dintre ele, necesare tuturor domeniilor de aplicaie i grupurilor de utilizatori principali; furnizarea unui model de date care s accepte efectuarea oricrei tranzacii necesare asupra datelor; specificarea unui proiect minimal, structurat n mod adecvat pentru realizarea cerinelor stabilite privind performanele sistemului, cum ar fi timpul de rspuns. n proiectarea unui sistem de baze de date se pot utiliza mai multe strategii de abordare dintre care cele mai cunoscute sunt:
Proiectare de jos n sus (bottom-up sau ascendent), care ncepe prin definirea atributelor, a asociaiilor dintre atribute, i n final gruparea acestora n entiti. Un astfel de tip de abordare este reprezentat de procesul de normalizare. Normalizarea implic identificarea atributelor necesare i plasarea lor n tabele normalizate, bazate pe dependenele funcionale dintre atribute. Acest tip de proiectare a unui sistem de baze de date este indicat n proiectarea unor baze de date simple, cu un numr relativ mic de atribute. Proiectare de sus n jos (top-down sau descendent), este indicat n proiectarea unor aplicaii de tip baze de date complexe. Aceasta ncepe cu realizarea unor modele de date, care conin cteva entiti i relaii de nivel nalt, dup care se aplic rafinri succesive de sus n jos, pentru a identifica entitile, relaiile i atributele asociate de nivel jos. Acest tip de abordarea este specific modelului Entitate - Relaie, care ncepe cu identificarea entitilor i relaiilor dintre ele care prezint interes pentru organizaie.
De asemenea, toate metodologiile utilizate n etapa de proiectare (numit i etapa de modelare) a bazelor de date cuprind trei etape principale, i anume:
Proiectarea conceptual (elaborarea modelului conceptual) reprezint procesul de construire a
unui model al informaiilor utilizate n cadrul unei organizaii, independent de toate consideraiile fizice. Aceast faz este complet independent de detaliile de implementare (elementele software ale SGBD-ului, programe de aplicaii, limbaje de programare, platforma hardware, etc.). Proiectarea logic (elaborarea modelului logic) reprezint procesul de construire a unui model al informaiilor utilizate n cadrul unei organizaii, bazat pe un anumit model de date, dar independent de un anumit SGBD i de alte consideraii fizice. Proiectarea fizic (elaborarea modelului fizic) reprezint procesul de realizare a unei descrieri a implementrii bazei de date ntr-o capacitate de stocare secundar; descrie structurile de stocare i metodele de acces utilizate pentru realizarea unui acces eficient la date. Modelul rezultat n urma acestei etape este cel care st la baza materializrii bazei de date propriu-zise. Proiectarea bazei de date se poate realiza n dou moduri: pornind de la o baz de date existent, utiliznd procedeul reverse engineering (proiectare invers); pornind de la zero, elabornd pe rnd cele trei modele enumerate mai sus utiliznd procedeul forward engineering (proiectare direct). Cnd un administrator de baze de date este ntrebat ce instrument CASE (Computer Aided Software Engineering) folosete n proiectarea, implementarea i analiza bazelor de date, unii vor rspunde Oracle Designer, alii CA ERWin/ERX sau Embarcadero ERStudio, iar alii vor opta pentru Rational Rose i lista poate continua. Desigur, opiunile de alegere a unui anumit instrument sunt dictate, n general, de preferine de natur subiectiv cunoaterea respectivului instrument fiind decisiv n alegerea produsului.
6.1. Proiectarea bazelor de date utiliznd regulile de business

Una din metodele propuse de Microsoft pentru proiectarea conceptual a unei baze de date este ORM (Object Role Modeling). n Microsoft Visio for Enterprise Architects se poate utiliza o diagram de tip ORM pentru a elabora modelul conceptual al unei baze de date. Modelul rezultat este independent de platforma pe care se va implementa baza de date rezultat. Dar ce reprezint ORM ? ORM reprezint o descriere general a bazei de date, utiliznd simboluri intuitive pentru obiecte i atribute i care verbalizeaz (exprim) relaiile dintre acestea, utiliznd o gam larg de constrngeri care surprinde i foreaz regulile de afaceri. De asemenea, ORM este un mod de abordare conceptual de un nivel nalt, utilizat pentru modelarea datelor care descrie domeniul aplicaiei (lumea este vzut n termeni ai obiectelor, i a rolurilor pe care aceste obiecte le ndeplinesc) utiliznd n acest scop simboluri intuitive i un limbaj natural pe care att utilizatorii ct i proiectanii bazei de date le poate nelege. Fiecare tip de element al faptului care are loc ntre tipuri de obiecte este verbalizat i afiat ntr-o diagram de schem conceptual. n acelai timp, ORM permite folosirea unui set extins de constrngeri pentru a surprinde regulile de afaceri (business rules), precum i ncorporarea unor exemple pentru verificarea proiectului. Procedura de proiectare a schemei conceptuale ORM se caracterizeaz prin analiza i proiectarea datelor. Schema conceptual specific structura informaional a aplicaiei prin intermediul tipurilor de fapte. Un model surs ORM poate fi folosit n loc de, sau naintea unui alt model de proiectarea a bazei de date. ORM permite: Proiectarea conceptual a bazei de date folosind fapte i exemple descrise ntr-un limbaj natural. Construirea automat a modelelor logice i fizice ale bazei de date pe baza faptelor exprimate ntr-un limbaj natural. Modelul bazei de date este creat ntr-un limbaj care poate fi neles de utilizatorii non-tehnici. Dintre caracteristicile mai importante ORM enumerm: este uor de neles exprim fapte i reguli n limba englez i / sau alte grafice intuitive; este fiabil valideaz regulile folosind limba englez i mostre de date; este expresiv surprinde n mod grafic multe reguli de business i mai complexe; este stabil minimizeaz impactul modificrilor asupra modelului i interogrilor.
BIBLIOGRAFIE
[Andronie, 2007] [Bocu, 2002] [Bodur&alt, 1982] [Bosksenbaum, 2002] [Davidescu, 1998] [Davidescu, 1999] [Georgescu, 2002] [Lungu1&alt, 1995] [Lungu&alt, 1995] [Lungu&alt, 2003] [Meyer, 1997] [Nistor&alt, 2003] [Oprea, 1999] [Roca&alt, 1993] [Vtui, 2000] [Vrlan, 2001] [Vrlan, 2004] Andronie M., Analiza i proiectarea sistemelor informatice de gestiune, Editura Fundaiei Romne de Mine, Bucureti, 2007 Bocu D., Iniiere n modelarea obiect orientat a sistemelor utiliznd UML, Grupul microINFORMATICA, Cluj-Napoca, 2002 Bodur-Lescu Gh., Ciobanu Gh., Bncil I., Analiza drumului critic, Editura tiinific i Enciclopedic, Bucureti, 1982 Boksenbaum L., Informatic de gestiune, Editura Economic, Bucureti, 2002 Davidescu N.D., Sisteme informatice financiar-bancare. Concepte fundamentale. Modelare prin metoda MERISE, vol. I, Editura ALL BECK, Bucureti, 1998 Davidescu N.D., Sisteme Informatice financiar-bancare - Metoda Merise, Vol II Aplicaii Practice, Editura ALL Beck, Bucureti,1999 Georgescu C., Abordarea relaional i obiectual n analiza sistemelor informatice, Editura Didactic i Pedagocic, Bucureti 2002 Lungu I., Bodea C., Bdescu G., Ioni C., Baze de date. Organizare, proiectare i implementare, Editura All Educational, Bucureti, 1995 Lungu I., Sabu Gh., Bodea C., Surcel Tr., Sisteme informatice pentru conducere, Editura Siaj, Bucureti, 1995 Lungu I., Sabau Gh., Velicanu M., Muntean M., Ionescu S., Posdarie E., Sandu D., Sisteme informatice. Analiz, proiectare i implementare, Editura Economic, Bucureti, 2003 Meyer B., Object Oriented Software Construction, Second Edition, Prentice Hall, 1997 Nistor R., Nistor C., Cpn Al., Metodologii manageriale informatice, Editura Academica, Galai, 2003 Oprea D., Analiza i proiectarea sistemelor informaionale economice, Editura Policrom, Iai, 1999 Roca I., Macovei E., Davidescu M., Rileanu V., Proiectarea sistemelor informatice financiar-contabile, Editura Didactic i Pedagogic, Bucureti, 1993 Vtui M., Metode de analiz orientat obiect a sistemelor informaionale Tez de doctorat, A.S.E. Bucureti, 2000 Vrlan G., Utilizarea limbajului de modelare UML n analiza i proiectarea sistemelor, Editura Mongabit, Galai, 2001 Vrlan G., Tehnologii client/server n dezvoltarea sistemelor informatice n economie, Editura Didactic i Pedagogic R.A., Bucureti, 2004
Bibliografie - 87

Proiectarea Sistemelor Informatice de Gestiune

Încărcat de

Informații document

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?

Drepturi de autor:

Formate disponibile

Proiectarea Sistemelor Informatice de Gestiune

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA DANUBIUS GALAI DEPARTAMENTUL DE STUDII PENTRU NVMNT LA DISTAN

GABRIELA VRLAN Cristina Maria Enache Cristina Gabriela Zamfir

Proiectarea sistemelor informatice de gestiune

EDITURA FUNDAIEI ACADEMICE DANUBIUS GALAI 2008

Proiectarea sistemelor informatice de gestiune

Capitolul 2 Sisteme informatice .........................................................................................................13

Curs 3 Stadiul actual i tendinele dezvoltrii sistemelor informatice ................................ 27

Capitolul 4 Metodologii de realizare a sistemelor informatice ................................................ 37

Capitolul 5 Analiza i proiectarea orientat obiecte .............................................................. 50

Proiectarea sistemelor informatice de gestiune

Capitolul 6 Metode de proiectare a bazelor de date .................................................................. 84 BIBLIOGRAFIE ...................................................................................................................................... 87

Proiectarea sistemelor informatice de gestiune

Capitolul 1 Noiuni fundamentale

1.1. Noiunea de informaie

Proiectarea sistemelor informatice de gestiune

1.2. Noiunea de sistem

Proiectarea sistemelor informatice de gestiune

1.3. Noiunea de sistem cibernetic

Proiectarea sistemelor informatice de gestiune

1.4. Noiunea de sistem informaional

Proiectarea sistemelor informatice de gestiune

Proiectarea sistemelor informatice de gestiune

1.5. Noiunea de sistem informatic

Proiectarea sistemelor informatice de gestiune

Noiuni fundamentale 1010

Proiectarea sistemelor informatice de gestiune

Noiuni fundamentale 1111

Proiectarea sistemelor informatice de gestiune

Noiuni fundamentale 1212

Proiectarea sistemelor informatice de gestiune

Capitolul 2 Sisteme informatice

2.1. Categorii de produse software

Proiectarea sistemelor informatice de gestiune

Proiectarea sistemelor informatice de gestiune

Clasificarea sistemelor informatice 1515

Proiectarea sistemelor informatice de gestiune

Clasificarea sistemelor informatice 1616

Proiectarea sistemelor informatice de gestiune

Proiectarea sistemelor informatice de gestiune

Proiectarea sistemelor informatice de gestiune

filtrarea i sortarea mesajelor primite; utilizarea de ageni inteligeni.

2.2. Alte tipuri de produse software

Proiectarea sistemelor informatice de gestiune

Proiectarea sistemelor informatice de gestiune

Proiectarea sistemelor informatice de gestiune

2.3. Clasificarea sistemelor informatice

Conducerea proceselor tehnologice

Cercetare tiinific i proiectare tehnologic

Clasificarea sistemelor informatice 2222

Curs 3 Stadiul actual i tendinele dezvoltrii sistemelor informatice

Stadiul actual i tendinele dezvoltrii sistemelor informatice 2929

3.1. Evoluia sistemelor informaionale n cadrul firmelor

3.2. Sisteme integrate pentru firme

Stadiul actual i tendinele dezvoltrii sistemelor informatice 3333

Stadiul actual i tendinele dezvoltrii sistemelor informatice 3434

3.3. Sistemul informatic de gestiune

Stadiul actual i tendinele dezvoltrii sistemelor informatice 3636

Capitolul 4 Metodologii de realizare a sistemelor informatice

Metodologii de realizare a sistemelor informatice 3737

4.1. Etape n proiectarea unui sistem informatic

4.2. Modele utilizate n proiectarea unui sistem informatic

Metodologii de realizare a sistemelor informatice 4040

Modelul incremental (rapid-prototyping) a fost creat pentru a acoperi deficienele modelului

4.3. Metodologii de analiz i proiectare a sistemelor informatice