| CATEGORII DOCUMENTE |
CAPITOLUL I
SISTEMUL INFORMATIC AL FIRMEI
Etapa actuala este etapa in care economia mondiala trece de la societatea predominant industriala la societatea informationala, guvernata de un set nou de reguli, in care tehnologiile digitale permite accesarea, procesarea, stocarea si transmiterea informatiilor. Complexitatea activitatilor desfasurate la nivelul firmelor reclama o viziune sistemica, in care fiecare componenta este parte a unui intreg.
Utilizat in toate domeniile de activitate, conceptul de sistem nu are o definitie unanim acceptata. La inceput a fost definit ca multime de elemente aflate in interactiune. Mai tarziu, observand ca aceasta definitie nu cuprinde sistemele logice formalizate, S. Cleen a definit sistemul ca o multime pentru care sunt definite relatii. Generalizand, o multime formeaza un sistem daca pe ea se realizeaza o relatie data, cu proprietati fixate. Sistemele astfel definite pot fi clasificate in functie de caracterul proprietatilor si al relatiilor. W. Ashby a observat ca definitia este mult prea larga, dat fiind faptul ca in orice multime pot fi definite mai multe tipuri de relatii si a propus definirea sistemului pornind de la comportamentul sau. A afirmat ca "sistemul se reprezinta ca posibilitate de constructie in sens larg, cu presupunerea ca exista capacitatea de a se da o anumita apreciere rezultatelor constructiei".
Dificultatile cognitive aparute in studiul obiectelor complexe din sfera cunoasterii stiintifice moderne, au determinat in timp constituirea teoriei generale a sistemelor, disciplina stiintifica care elaboreaza principiile metodologice de investigare a sistemelor, care asigura o baza formal metodologica unitara de cercetare.
1.1 Sistem informational
In cadrul teoriei sistemelor, un loc important il ocupa sistemele deschise, sisteme ce pot realiza o stare de echilibru dinamic cu mediul exterior. Principalele caracteristici structurale raman constante, in timp ce sistemul realizeaza un schimb continuu de informatii cu mediul. Sistemele economice sunt considerate cazuri particulare ale sistemelor deschise.
Privita ca sistem, o firma poate fi structurata la randul ei in trei mari subsisteme: subsistemul operational (condus), subsistemul decizional (de conducere) si subsistemul informational (de legatura). Fiecare din aceste subsisteme poate fi considerat ca un sistem de sine statator ( fig. 1.1.a).
Sistemul informational este reprezentat de totalitatea metodelor, procedurilor si mijloacelor folosite in procesul informational. El poate fi definit ca un ansamblu organizat si integrat de operatii de culegere, transmitere, prelucrare, sistematizare, analiza si pastrare, difuzare si valorificare a informatiilor.
Permitand actualizarea datelor de intrare si legarea informatiilor din toate domeniile de activitate, sistemul informational trebuie sa fie capabil sa furnizeze rapoarte periodice privind desfasurarea activitatii, dar si rapoarte la cerere, determinate de semnalarea unor situatii neobisnuite. Ele fundamenteaza activitatea de analiza si prognoza, permit luarea rapida si eficienta a masurilor ce se impun.
Rolul determinant al informatiilor in procesul conducerii a impus definirea unei noi notiuni, decizia, ca fiind o informatie de comanda pentru sistemul operational. Eficienta deciziilor luate depinde de calitatea informatiilor furnizate. Impreuna cu datele ce exprima inregistrarea fenomenelor si proceselor la momentul producerii lor, informatiile si deciziile realizeaza legatura intre sistemul operational si cel de conducere.
Scopul principal al sistemului informational este de a furniza fiecarui utilizator toate informatiile necesare. Preluand datele de la sistemul operational, sistemul informational asigura pe de o parte informatiile necesare fundamentarii deciziilor, primeste si transmite deciziile formulate de sistemul de conducere, iar pe de alta parte asigura legatura dintre mediul intern al firmei si cel exterior ei.
Noua economie, specifica societatii informationale, transforma informatia digitala in valoare economica si sociala, creeaza noi industrii modificandu-le pe cele existente, afectand profund viata cetatenilor. Informatiile traduse intr-un limbaj universal (computerizat) sunt privite ca o materie prima strategica, fundamentala dezvoltarii economice si sociale. Cuplata cu retelele de calculatoare, informatia digitizata circula in timp real. Schimba procesele de productie, metodele de cercetare, organizarea muncii si obiceiurile consumatorilor.
In aceste conditii, locul sistemul informational traditional este preluat de retelele Intranet. Intranet-ul este o retea locala cu arhitectura bazata pe tehnologia Internet, care permite comunicarea intr-un grup inchis de utilizatori care se raporteaza si construiesc o baza comuna de informatii. Schimbul de informatii cu mediul exterior este preluat de Extranet, o aplicatie speciala care permite altor organizatii si persoane accesul la informatia difuzata pe Intranet. Cu aceste consideratii, subsistemele dintr-o firma pot fi reprezentate ca in figura 1.b.
1.2 Sistem informatic
Sistemul informatic este un ansamblu structurat si corelat de proceduri si echipamente electronice de calcul care permit culegerea, transmiterea si prelucrarea datelor, obtinerea de informatii.
Sistemul informatic largeste campul de actiune al sistemului informational, ii potenteaza valentele, imbunatatindu-l sub aspect calitativ. Odata cu evolutia sistemelor electronice de calcul, sistemul informatic tinde sa se suprapuna sistemului informational ca sfera de cuprindere. Mai mult, daca se include in sfera sistemul informatic activitatea de conducere a proceselor tehnologice cu ajutorul calculatoarelor de proces, sfera sistemelor informatice depaseste sfera sistemelor informationale.
In activitatea economica, sistemele informatice privesc obtinerea informatiilor pe baza unor date de intrare si a unor normative, procedeele de prelucrare fiind considerate elemente interconditionate si inseparabile ale procesului de conducere. Sunt sisteme informatice integrate, caracterizate prin aplicarea principiului introducerii unice a datelor si prelucrarii multiple a acestora in concordanta cu cerintele informationale specifice fiecarui utilizator.
Utilizate in managementul firmei, sistemele informatice integrate (fig. 1.2) au la baza sistemele tranzactionale, concepute sa eficientizeze si sa automatizeze prelucrarea, sa pastreze inregistrarile si sa raporteze tranzactiile. Acestea sunt in permanenta interdependenta cu sistemele de birotica si comunicatii, utilizate pentru automatizarea muncii de birou. Impreuna contribuie la definirea depozitelor de date, structuri pe care se bazeaza sistemele informatice de analiza.
1.2.1 Structura generala a unui sistem informatic
Evidentierea structurii generale a unui sistem informatic se obtine pornind de la functia acestuia de a prelucra datele in vederea obtinerii informatiilor necesare unei desfasurari normale a activitatilor intr-o firma. Principalele componente sunt: intrari, prelucrari, iesiri.
Intrarile sunt reprezentate de multimea datelor incarcate, gestionate si prelucrate in cadrul sistemului.
Prelucrarile reprezinta un ansamblu omogen de proceduri automate cu functie de:
. creare si actualizare a bazei de date;
. consultare a bazei de date;
. reorganizare a bazei de date;
. salvare/restaurare a bazei de date.
Iesirile sistemului informatic sunt reprezentate de rezultatele prelucrarilor desfasurate. Iesirile pot fi obtinute in urma unor operatii de transfer a datelor, sau pot fi obtinute in urma operatiilor de calcul ce au la baza algoritmi prestabiliti.
In functie de continutul si forma lor de reprezentare, iesirile pot fi clasificate astfel:
. indicatori sintetici, regasiti in tablourile de bord oferite managerilor (cifra de afaceri, profitul brut, profitul net).
. rapoarte, situatii ce regrupeaza diferiti indicatori sintetici sau analitici (balanta de verificare, bilantul contabil, statul de plata).
. grafice, ce permit reprezentarea intr-o forma sugestiva a dinamicii indicatorilor sintetici si analitici, a modificarilor de structura.
. foi de calcul electronice, generate cu ajutorul procesoarelor de tabele (Excel). Rezultatul obtinut poate fi furnizat direct utilizatorilor, sau poate fi obiectul importului/exportului catre sisteme de gestiune a bazelor de date.
. iesiri destinate altor sisteme, reprezentate de fisiere transmise on-line sau off-line in vederea prelucrarilor ulterioare in cadrul altor sisteme informatice.
1.3 Proiectarea sistemelor informatice
In general proiectarea sistemelor informatice desemneaza activitatea complexa de dezvoltare de sisteme informatice. Indiferent de metodologie, proiectarea urmareste intregul ciclu de viata al sistemului informatic. In etape distincte, pe diferite nivele de abstractizare, sunt construite modele ce evidentiaza cele trei dimensiuni: statica, dinamica si functionala.
In sens restrans, proiectarea sistemelor informatice este una din etapele in care sunt grupate activitatile desfasurate pentru realizarea unui sistem informatic. Urmand analizei si precedand implementarea, proiectarea extinde sau adapteaza modelele definit in faza de analiza, tinand cont de restrictiile impuse de mediul in care va functiona sistemul. Introduce elemente noi necesare trecerii la implementare.
La ora actuala, tendinta de standardizare in conceperea sistemelor informatice determina o diminuare a fazei de proiectare, prioritate avand modalitatile de implementare si identificarea efectele pe care noul sistem le poate avea asupra unitatii beneficiare. Faza de proiectare se reduce la elaborarea unor specificatii tehnice de implementare.
1.3.1 Principiile proiectarii si realizarii sistemelor informationale
Principiile ce trebuie respectate in activitatea de proiectare si realizare a sistemelor informatice sunt [SV03]:
Abordarea globala a problemei de rezolvat.
Utilizarea unei metodologii unitare in proiectarea si realizarea sistemului informatic
Aplicarea celor mai moderne solutii si tehnici de proiectare si realizare a sistemului informatic
Structurarea sistemului informatic independent de structura organizatorica a firmei.
Participarea nemijlocita a viitorului beneficiar la activitatile de analiza, proiectare si implementare a sistemului informatic.
Respectarea cadrului legislativ.
Realizarea unor sisteme informatice in concordanta cu resursele disponibile la utilizator.
Anticiparea si controlarea permanenta a schimbarilor survenite.
Explicitarea si documentarea compromisurilor inerente in dezvoltarea de software.
Conform acestor principii, se defineste intai o solutie globala de informatizare, se stabileste structura flexibila a sistemului si se precizeaza prioritatile in realizarea componentelor sale. Asigurand implicarea benefi-ciarului pe tot parcursul realizarii sistemului informatic, se iau in calcul particularitatile privitoare la modul de organizare a activitatii, cadrul legislativ general si reglementarile interne aflate in vigoare.
1.3.2 Strategii de proiectare a sistemelor informatice
In functie de modalitatea de abordare a sistemelor informatice, strategiile de proiectare a sistemelor informatice pot fi grupate in trei mari clase: strategii descendente, strategii ascendente si strategii mixte.
Strategia descendenta (top-down) porneste de la principiul descompunerii sistemului informatic complex in componente mai simple prin parcurgerea unor nivele succesive de detaliere. Se defineste astfel o structura ierarhic-modulara in care fiecare componenta indeplineste o anumita functie.
Strategia descendenta se aplica in cazul sistemelor informatice complexe (sistemul informatic al unei banci, sistemul informatic al Ministerului de Finante). Initial se realizeaza o solutie globala la nivelul intregului sistem. Componentele se proiecteaza si se realizeaza independent, intr-o ordine de prioritate stabilita de cerintele sistemului ca un tot unitar si in functie de cerintele beneficiarului. Integrarea se realizeaza din treapta in treapta pornindu-se de la componentele elementare.
Practic, strategia descendenta consta in:
. identificarea entitatilor, componente relevante, interesante prin structura si comportarea lor; entitatile trebuie sa aiba cel putin o realizare si cel putin un atribut;
. identificarea asocierilor dintre entitati;
. identificarea asocierilor de tipul generalizare/specializare si parte/intreg. Dupa realizarea generalizarilor/specializarilor se reactualizeaza lista entitatilor care urmeaza sa fie incluse in modelul datelor. Specializarea este necesara cand o serie de asocieri intre entitati au sens doar la nivelul unei specializari si cand nu toate atributele sunt valabile pentru toate realizarile de entitate. Generalizarea se impune cand entitati diferite prezinta atribute similare sau asocieri analoage cu alte entitati.
. identificarea proprietatilor de entitate si stabilirea cheilor;
. identificarea proprietatilor de asociere;
. construirea modelului;
. verificarea modelului.
Strategia ascendente (bottom-up) presupune proiectarea si realizarea componentelor viitorului sistem informatic, fara a avea o imagine de ansamblu asupra intregului sistem informational. Se trateaza separat fiecare componenta a sistemului, stabilirea corelatiilor intre componente si integrarea lor in sistemul privit ca un tot unitar urmand a se face ulterior. Lipsa unei strategii unitare aduce dupa sine riscul unui grad redus de integrare a componentelor in sistem.
Practic, strategia ascendenta consta in:
. identificarea proprietatilor ;
. construirea grafului dependentelor functionale; In cadrul dependen-telor functionale, arcele terminale obtinute plecand de la proprietatile elementare definesc entitatile. Originile arcelor constituie identificatorii de entitate. Arcele care raman pun in evidenta asocierile. Proprietatile nerezolvate ce raman sunt atribuite asocierilor. Proprietatile izolate vor defini entitatile izolate.
. determinarea structurilor teoretice de acces la date;
. construirea modelului;
. verificarea modelului.
Strategia mixta reprezinta o combinare a strategiei descendente cu strategia ascendenta, imprumutand de la fiecare avantajele. Practic se foloseste strategia descendenta pentru definirea sistemului ca un tot unitar si a componentelor lui, urmandu-se strategia ascendenta in proiectarea si realizarea fiecarei componente.
1.4 Ciclul de viata al unui sistem informatic
1.4.1 Caracteristici
Definirea unui sistem informatic este o decizie determinata de avan-tajele tehnologiilor informationale aduse mediului de afaceri. Impartirea in subsisteme, specificarea unor prioritati sau schimbarea conditiilor concrete de lucru, se regasesc atat in cerintele legate de functiile sistemului (fundamentarea deciziilor imediate, urmarirea productiei) cat si in cele nefunctionale, ce refera proprietatile calitative ale sistemului( flexibilitate, portabilitate). Gruparea activitatilor pe etape, faze si activitati specifice se face in functie de complexitatea modelului real, de cerintele utilizatorului sau de abilitatile echipei de realizare a sistemului informatic.
In "Proiectarea obiectuala a sistemelor informatice" ([ZR02]) autorii definesc ciclul de viata al unui sistem informatic ca fiind perioada de timp cuprinsa intre momentul initierii acestuia si momentul scoaterii din functiune. Aceasta perioada este impartita in doua etape fundamentale: dezvoltarea si exploatarea.
1. Dezvoltarea include perioada de timp necesara obtinerii sistemului, trecerea la realizarea planului insemnand inceputul perioadei de dezvoltare.
In timp ce proiectarea informationala vizeaza modul de functionare a sistemului din punctul de vedere al utilizatorilor, modul in care se va derula activitatea la intrarea in functiune a sistemului, proiectarea informatica vizeaza arhitectura logica si fizica, mediul de dezvoltare sau de programare, programe, baze de date.
2. Exploatarea cuprinde perioada de timp in care sistemul este folosit in mod curent.
1. Definirea cerintelor utilizatorilor, cand se precizeaza obiectivele noului sistem, criteriile de eficienta, securitatea, performantele.
2. Specificatia cerintelor sistemului, prezentarea detaliata a rezultatelor pe care sistemul informatic le va asigura.
3. Specificatia cerintelor software, luand in calcul restrictiile sub care functionalitatea sistemului urmeaza sa fie asigurata.
4. Proiectarea generala, cand se defineste solutia cadru, conceptuala.
5. Proiectarea de detaliu, faza in care se rafineaza solutia cadru si se defineste solutia finala.
6. Realizarea componentelor sistemului informatic rezultate din elaborarea arhitecturii.
7. Testarea componentelor, cand se verifica modul de functionare, modul de indeplinire a cerintelor si fiabilitatea in functionare.
8. Integrarea componentelor si testarea finala a sistemului, faza ce presupune realizarea produsului final si verificarea functionalitatii lui.
9. Implementarea si testarea produsului la beneficiar.
10. Exploatarea si intretinerea sistemului.
11. Dezvoltarea sistemului, ce implica realizarea si integrarea de noi componente.
Etapele ciclului de viata se pot derula strict secvential, sau pot determina reveniri la etapa anterioara (chiar la prima etapa), in functie de rezultatul validarilor intermediare. In functie de complexitatea sistemelor reale, schimbarile din domeniul tehnologiei informatiilor se reflecta fie in schimbarea etapelor, fie in modificarea opticii de parcurgere a lor.
Ordinea si felul in care se parcurg etapele se regaseste in literatura de specialitate sub numele de modele ale ciclului de viata al dezvoltarii sistemelor.
1.4.2 Modele ale ciclului de viata
Dintre modelele ciclului de viata care au ocupat un loc important in teoria sistemelor la vremea cand au fost definite, si ale caror avantaje au fost preluate chiar si de cele mai actuale modele, se pot mentiona modelul cascada si modelul spirala.
Modelul cascada (Waterfall) a fost elaborat la inceputul anilor 1970, de catre W.W. Royce. Ciclul de viata este descompus in faze secventiale, structurate in activitati si subactivitati. Trecerea la etapa urmatoare presupune parcurgerea in intregime a celei curente.
Avantaje:
fiecare etapa este insotita de documentare si se incheie cu verificarea solutiei oferite;
prin ordonarea si delimitarea clara a fazelor, se obtine un control total al fazelor;
este usor de insusit de catre membrii echipelor de analiza si proiectare.
Dezavantaje:
respectarea ordinii secventiale a etapelor nu este intotdeauna conforma cu realitatea;
necesitatea parcurgerii integrale a etapelor anterioare duce la prelun-girea timpului de realizare al sistemului;
nu ia in calcul eventualele schimbari intervenite pe parcurs .
Datorita acestor dezavantaje, in timp au fost propuse variante imbunatatite, acceptand reluarea pasului anterior ( waterfall model with back flow) sau reluarea de la faza initiala ( "Da Capo" waterfall model), permitand astfel corectarea erorilor ivite pe parcurs.
Modelul spirala a fost elaborat de B. W. Boehm, in 1988. Dezvoltarea sistemului se face in spirala. Pentru fiecare nivel se face analiza riscului si se construiesc prototipuri succesive. La fiecare iteratie sunt reluate fazele de dezvoltare, ce includ simularea si testarea prototipului, determinarea si validarea cerintelor rezultate din testare, planificarea ciclului urmator, regasindu-se modelul cascada. Dupa efectuarea studiilor de fezabilitate, sistemul se realizeaza, se integreaza si se instaleaza in varianta modelului cascada.
Conditionat de profesionalismul echipei de dezvoltare, avantajul acestui model consta in faptul ca ofera posibilitatea evaluarii riscurilor in diferite momente.
1.5 Metode de proiectare a sistemelor informatice
Ansamblul modelelor pentru un sistem informatic este elaborat conform unei metode, definita printr-un proces, o notatie si un set de instrumente informatice [ZR02].
Metoda, cunoscuta sub numele de metoda de proiectare, specifica activitatile ce trebuie efectuate pentru conceperea sistemului, ordinea in care se executa si modul lor de corelare. Pentru fiecare activitate sunt definite intrarile, iesirile si sunt formulate instructiunile de realizare.
1.5.1 Clasificari
Intr-o prima clasificare, metodele de proiectare pot fi grupate in metode hard si metode soft.
Metodele hard pun accentul pe abordarea stiintifica si considera ca realitatea, independenta de oameni, poate fi modelata, inteleasa si transformata in functie de dorintele acestora. Considera ca toate problemele pot fi formalizate pe baze matematico-logice si acorda proiritate datelor, functiilor si proceselor.
Metodele soft, dintre care cea mai cunoscuta este metoda SSM (Soft System Methodology) introdusa de P Checkland in 1981, incearca sa rezolve probleme legate de aspectele sociale ale dezvoltarii sistemelor, de cerintele utilizatorilor. Din punctul lor de vedere, analistul se confrunta cu situatii problema si nu cu probleme clar definite si gata de rezolvare. Masurile luate intr-o situatie sunt rezultatul schimbarii organizationale, analistul de sistem fiind vazut nu ca un expert in domeniu ci ca un agent al schimbarii, capabil sa-i stimuleze pe ceilalti in obtinerea unor noi perceptii asupra contextului problemei.
O alta clasificare, recunoscuta mai ales in literatura franceza, imparte metodele in functie de modalitatea in care este perceput sistemul. Exista astfel metode de analiza si descompunere ierarhice (functionale), metode de analiza si reprezentare orientate-sistemic si metode de analiza si proiectare orientate-obiect.
...
Caracterizate prin simplitate si o buna adaptare la cerintele utilizatorului, aceste metode prezinta dezavantajul ca orice schimbare de functie a sistemului presupune reconsiderarea aplicatiilor. In plus, efortul este centrat asupra functiilor de prelucrare, neglijandu-se coerenta datelor.
Cele mai cunoscute metode ierarhice sunt: SADT (Structurated Analysis and Design Technique), JSD (Jackson System Development, Yourdon.
Metodele sistemice reprezinta cea de-a doua generatie a metodelor de analiza si proiectare a sistemelor informatice. Bazandu-se pe teoria generala a sistemelor, in cadrul acestor metode datele si prelucrarile asupra datelor sunt modelate si studiate independent. Impreuna formeaza un sistem. Axandu-se pe conceptul de baza de date, care ofera coerenta si elimina redundantele, metodele sistemice acorda prioritate datelor fata de prelucrari. Dezavantajele acestor metode rezulta din existenta deficientelor in modelarea prelucrarilor, in prezenta unor discordante intre modelele datelor si cele ale prelucrarilor.
Metodele sistemice respecta cele trei nivele de abstractizare introduse prin metodologia ANSI/SPARC: conceptual, logic si fizic. Principalele metode sistemice sunt: MERISE, AXIAL, Information Engineering.
Metodele orientate obiect reprezinta cea de-a treia generatie, utilizate astazi in cazul sistemelor cu comportament dinamic, dependent de timp. Se definesc entitati de sine statatoare, in care sunt incapsulate date (proprietati) si prelucrari (operatii).
Avantajul acestor metode rezulta din faptul ca ofera posibilitatea reutilizarii componentelor. Existand o integrare mult mai buna a datelor cu prelucrarile, aduc o rezolvare coerenta a aspectelor dinamice. Dezavantajul este insa ca nu intotdeauna modelarea corespunde realitatii reprezentate.
Cele mai utilizate metode sunt: Object Modeling Technologie (OMT), Object Oriented Design (OOD). Succesul utilizarii metodelor orientate obiect a determinat definirea unui limbaj standard de modelare, Unified Modeling Language.
CAPITOLUL II
METODE SISTEMICE
Dintre metodele sistemice, cea mai reprezentativa este metoda MERISE, aplicata pentru prima data in 1979 in Franta. Perfectionata continuu, este utilizata si astazi cu prioritate in informatica de gestiune. Este motivul pentru care, in lucrarea de fata, principalele particularitati ale metodelor sistemice sunt prezentate prin prisma acestei metode.
2.1 Nivele de descriere
In "Merise vers OMT et UML" ([GJ99]), prezentand descrierea sistemului de la abstract la concret, autorii grupeaza nivelele de abstractizare in doua mari clase. Intr-o prima clasa, nivelul conceptual si nivelul organizational, corespund descrierii sistemului informatic independent de solutia informatica. Nivelul logic si nivelul fizic constituie a doua clasa, in care este luata in calcul solutia informatica aleasa.
Nivelul conceptual urmareste obtinerea unei reprezentari fidele a realitatii, facand abstractie de restrictiile informatice sau organizatorice. Surprinde cu ajutorul unor abstractii aspectul static si dinamica in timp a activitatii desfasurate.
Nivelul organizational leaga functionalitatea sistemului de organizarea firmei si de postul de lucru. Executate in timp real sau nu, procedurile manipuleaza date din diferite compartimente functionale. La acest nivel, procedurile sunt descompuse in faze executate pe posturi de lucru.
Nivelul logic vizeaza alegerea solutiei informatice pentru culegerea datelor si furnizarea informatiei. Procedurile sunt detaliate la nivel de module.
Nivelul fizic este nivelul concret la care sunt definite mijloacele tehnice de realizare efectiva a sistemului.
Cele patru nivele presupun construirea unor modele separate pentru date si prelucrari, constituind impreuna ciclul de abstractizare al sistemului informatic
2.2 Modele pentru date si prelucrari
Pentru fiecare nivel exista un model al datelor si un model al prelucrarilor.
Nivelului conceptual ii sunt asociate modele rezultate din analiza sistemului real. Se regasesc in documentele redactate in urma proiectarii generale.
Modelul Conceptual al Datelor (MCD) defineste structura globala de organizare a datelor, asigurand independenta totala fata de orice sistem de gestiune a bazelor de date. Acordand prioritate datelor, pentru reprezentarea lor foloseste un formalism precis, normalizat pe plan international de ISO (International Standard Organization) sub numele de model "Entitate-Asociere". Este realizat cu ajutorul conceptelor de entitate (obiect), relatie, proprietati, proprii formalismului Entitate-Asociere.
Modelul Conceptual al Prelucrarilor (MCP) descrie latura dinamica a sistemului, evidentiind inlantuirea operatiilor si conditiile declansarii acestora. Utilizeaza conceptele de proces, operatie si eveniment.
La nivel organizational modelele definite apropie conceptia de ansamblu a sistemului de structura organizatorica. Utilizand un formalism identic cu cel al modelelor conceptuale, se definesc modele separate pentru date si prelucrari.
Modelul Organizational al Datelor (M0D) se construieste in cazul sistemelor informatice complexe, in care datele sunt distribuite pe diferite nivele organizatorice. El prezinta multimea datelor grupate pe unitati organizatorice. Existenta tehnologiilor client-server au crescut importanta distinctiei intre datele culese si valorificate la nivelul statiilor de lucru si datele gestionate de server.
Modelul Organizational al Prelucrarilor (MOP) se construieste in situatiile in care operatiile definite la nivel conceptual sunt executate in diferite compartimente functionale. Prezinta procedurile descompuse in faze si sarcini corespunzatoare posturilor de lucru.
Modelele logice fixeaza o solutie direct implementabila, stabilesc realizarea efectiva a sistemului informatic cu o baza de date relationala si un sistem de gestiune a bazelor de date corespunzator, sau cu ajutorul fisierelor de date exploatate cu limbaje procedurale. In cazul informaticii de gestiune, demersul metodologic conduce la implementare cu ajutorul bazelor de date relationale, datele fiind inmagazinate in structuri stabile (tabele) si manipulate cu un Sistem de Gestiune a Bazelor de Date performant.
Modelul Logic al Datelor (MLD) se obtine conform standardelor Modelului Relational al Datelor.
In cazul prelucrarilor, pentru ca nu exista o normalizare a descrierii logice a prelucrarilor, nu exista un Modelul Logic al Prelucrarilor ci o Descriere Logica a Prelucrarilor (DLP).
La nivel fizic sunt specificate efectiv modalitatile de realizare a solutiei informatice alese. Ne existand un standard pentru definirea modelelor fizice de date si prelucrari, acest nivel este reflectat in Descrierea Fizica a Datelor (DFD) si respectiv in Descrierea Fizica a Prelucrarilor (DFP).
Descrierea fizica a datelor este legata de sistemul de gestiune al bazelor de date ales pentru crearea bazei de date. Evidentiaza modul in care datele vor fi stocate si accesate la nivelul memoriei externe, sistemele care asigura securitatea pastrarii si regasirii datelor.
Descrierea fizica a prelucrarilor presupune realizarea solutiei stabilite in cadrul modelului logic al prelucrarilor, apeland la un anumit sistem de gestiune a bazelor de date.
2.3 Modelarea conceptuala si organizationala a datelor
In aceasta etapa, cand nu se pune problema unei solutii informatice, conceptele sunt abstractii ce reprezinta lumea reala ca o colectie de entitati si de legaturi intre acestea.
Construirea Modelului Conceptual al Datelor este primul pas in reprezentarea sistemelor reale in care se vehiculeaza un volum mare de date. Modelul Conceptual al Datelor este un mijloc de comunicare intre modelator (proiectantul sistemului informatic) si viitorul utilizator al sistemului. Impreuna stabilesc obiectele lumii reale si proprietatile lor, impreuna cuantifica restrictiile impuse de conditiile concrete ale desfasurarii activitatii sub forma simpla a unor reguli de gestiune.
In cazul in care exista mai multe compartimente functionale, cand datele sunt culese, prelucrate sau utilizate in posturi de lucru diferite, Modelul Conceptual al Datelor se detaliaza conform structurii organizatorice. Se obtine astfel Modelul Organizational al Datelor.
La ora actuala, cand majoritate firmelor beneficiaza de tehnica de calcul performanta, de retele Intranet, construirea modelului organizational al datelor presupune:
repartizarea datelor pe compartimente functionale;
asigurarea vizibilitatii datelor pe diferite nivele organizatorice;
stabilirea drepturilor de acces la date conform unui protocol determinat de arhitectura sau de topologia retelei existente;
stabilirea volumului de date active, a volumului si a conditiilor de arhivare pentru datele pasive.
2.3.1 Modelul Entitate-Asociere
Asa cum am mai afirmat, modelarea conceptuala si organizationala a datelor se face pe baza formalismului modelului Entitate-Asociere. Principalele concepte sunt: entitate, asociere, atribut. Modelul Entitate-Asociere prezinta lumea reala ca o colectie de clase si de legaturi de diferite tipuri intre ele. Fiind reprezentarea unui sistem real, in model trebuie evidentiate si modul in care realizarile fiecarei entitati sunt implicate intr-o asociere, numarul entitatilor care participa la o asociere. Vorbim astfel de cardinalitatea cuplului Entitate-Asociere, de tipul de asociere si de dimensiunea unei asocieri.
2.3.1.2 Caracteristici
entitate
ENTITATEA (E) este o reprezentare conceptuala a unui obiect sau fenomen din sistemul real. Are existenta proprie si este conforma cu regulile de gestiune ale firmei.
In activitatea de modelare nu intereseaza obiectele individuale, ci clasele in care ele pot fi grupate in functie de caracteristici comune. Existenta unei entitati este subordonata apartenentei la o clasa, numele clasei fiind folosit pentru a referi elementele unei clase. Componentele individuale sunt numite instante (realizari) ale claselor. Intre instanta si clasa sa se stabileste astfel, prin grupul verbal ,,este membru in", o relatie.
Exemple:
FURNIZORI, este o clasa ce defineste multimea persoanelor fizice/juridice de la care s-a cumparat sau s-a comandat cel putin un articol.
"4011-Remex" este membru in clasa ,, FURNIZOR"
CLIENTI, este o clasa ce defineste multimea persoanelor fizice/juridice care au comandat sau au cumparat cel putin un produs.
"4112-Amis" este membru in clasa "CLIENTI "
PRODUSE, este o clasa ce defineste multimea bunurilor materiale cuprinse in catalogul de vanzari al firmei.
" calculator" este membru in clasa "PRODUSE"
Prin abuz de limbaj, in multe din lucrarile ce vizeaza modelarea conceptuala se foloseste termenul de entitate in locul celui de clasa de entitati. Convenim ca si in lucrarea de fata sa acceptam ca o entitate este o clasa generica de obiecte avand aceleasi caracteristici pentru un modelator plasat intr-un context dat. In toate aceste situatii, entitatea este reprezentata cu ajutorul unui dreptunghi in care este scris numele entitatii si proprietatile ei.
asociere
ASOCIEREA (A) intre entitati exprima o legatura existenta sau posibila intre obiecte individuale. Clasele de asocieri sunt asocieri intre clasele de obiecte individuale.
Respectand conventia stabilita la definirea entitatii, vom spune ca o asociere este o clasa generica de legaturi recunoscute sau posibile intre obiecte apartinand entitatilor din sistem.
In cadrul Modelului Conceptual al Datelor, asocierea este reprezentata printr-o elipsa care face legatura intre entitatile participante la asociere.
Exemplu:
atribut
ATRIBUTUL defineste o proprietate distincta a unei entitati sau a unei asocieri. Un atribut este considerat o multime de valori posibile.
Identitatea unei entitati este exprimata printr-un atribut sau un grup minimal de atribute care permit identificarea unica a realizarilor ei. Altfel spus, fiecare entitate poseda un identificator, sau o cheie a entitatii. Pentru o entitate pot exista mai multe atribute care sa serveasca drept cheie. Acestea se numesc chei candidate. Selectarea se face in functie de necesitatile impuse de context, cheia principala putand fi formata din unul sau mai multe atribute. Atributele cheie se marcheaza prin subliniere sau printr-o sageata spre entitatea careia ii apartin si ale caror instante le identifica.
Celelalte atribute, care exprima caracteristicile entitatii sunt si ele specificate in cadrul entitatii. Fiecare realizare a unei entitati poseda valori proprii pentru atribute.
Exemplu:
Pentru entitatea FURNIZORI, codul fiscal sau denumirea pot fi considerate chei candidate. De cele mai multe ori, codul fiscal este ales cheie primara.
Entitatea FURNIZORI are ca atribute: CodFurnizor, Nume, Localitate; se reprezinta astfel:
O asociere poate avea atribute proprii. Atributele asocierii se specifica in elipsa ce cuprinde numele asocierii (CantitateCumparata).
Atributele pot fi clasificate in functie de mai multe criterii:
1. dupa realizarile pe care le pot prezenta
atribute cu realizari obligatorii, pentru care la momentul definirii se specifica " NOT NULL".
Exemplu: CodFurnizor, MaracSalariat.
atribute optionale, care pot sa nu prezinte realizari in cazul unor entitati.
Exemplu: adresa_e-mail a furnizorului, nr_telefon pentru angajati.
atribute monovaloare, care prezinta o singura valoare in cadrul unei entitati. Exemplu: NumeClient, CantitateLivrata.
atribute multivaloare, care prezinta mai multe valori in cadrul aceleiasi entitati.
Exemplu: in cazul in care o persoana cunoaste mai multe limbi straine ce trebuie evidentiate, atributul LimbaStraina este un atribut multivaloare; atributul numele autorului este atribut multivaloare in cazul in care o carte are mai multi autori.
2. dupa complexitatea atributelor
atribute elementare, cu realizari atomice.
Exemplu: MarcaSalariat, NumarMatricol, PretUnitar.
atribute decompozabile, ale caror realizari sunt formate dintr-un grup de valori de tipuri diferite, care pot fi descompuse in realizari atomice. Exemplu: atributele ce definesc Adresa sau DataCalendaristica.
Dintre atributele ce caracterizeaza entitatile definite in modelele sistemelor informatice economice, o atentie deosebita trebuie acordata factorului timp, care apare sub forma datei calendaristice. Raportate la acest atribut, entitatile pot fi grupate in entitati permanente (CLIENTI, PRODUSE, CREDITE) si entitati eveniment, ce evidentiaza schimbari, modificari, produse la un moment dat (COMENZI, FACTURI, PLATI). Acestea din urma, pe langa atributele ce le identifica unic, poseda un atribut care specifica data producerii lor (DataComenzii, DataFacturii, DataPlatii).
cardinalitate
Cardinalitatea da informatii despre numarul minim si numarul maxim de aparitii ale unei asocieri A intre o entitate E1 si o alta E2. Referind entitatea, (multimea legata prin aplicatie), si asocierea, (aplicatia multimii in alta multime), se vorbeste de cardinalitatea cuplului Entitate-Asociere (EA). Se defineste ca un cuplu de intregi (x,y), unde:
x reprezinta numarul minim de legaturi ce pot exista pentru o realizare data a entitatii.
y reprezinta numarul maxim de legaturi ce pot exista pentru o realizare data a entitatii.
Pentru cardinalitati, valorile semnificative utilizate in activitatea de modelare sunt fie 0 si 1 pentru cardinalitatea minimala, fie 1 si n pentru cardinalitatea maximala. Se evita astfel schimbarea modelului pe masura ce se dezvolta relatia intre doua entitati:
Daca la momentul modelarii potential exista o legatura intre realizarile a doua entitati, aceasta este reprezentata prin valoarea 0 a cardinalitatii minimale. Situatiile in care pot exista mai multe legaturi pentru o realizare data a unei entitati sunt reprezentate de la inceput prin valoarea n a cardinalitatii maximale. Se evita astfel schimbarea modelului pe masura ce se dezvolta relatia intre doua entitati.
Cardinalitatea minimala 0 precizeaza realizari de entitati care nu participa efectiv la asociere;
Exemplu:
Produsele obtinute in activitatea de productie pot fi stocate in depozit sau pot face obiectul vanzarii, fiind inscrise pe dispozitii de livrare. Altfel spus, un produs se poate afla sau nu pe o dispozitie de livrare (cardinalitatea minimala 0).
Cardinalitate minimala 1 este in cazul in care toate realizarile entitatii participa la o realizare a asocierii;
Cardinalitatea maximala 1 defineste situatia in care realizarile entitatii care participa la asociere nu se pot modifica, in care legatura exprimata de asociere nu se poate modifica;
Exemplu:
In activitatea de aprovizionare cu marfuri, factura care insoteste marfa contine datele furnizorului. Nu exista factura care sa nu aiba un emitent (cardinalitate minimala 1). In acelasi timp, pentru o factura nu pot exista mai multi furnizori cardinalitatea maximala 1).
Exemplu:
In aprovizionarea cu marfuri, de la un furnizor se pot primi mai multe facturi. Numarul lor fiind nedefinit, se considera cardinalitatea maximala n.
tip de asociere
O asociere poate lega intre ele doua sau mai multe entitati. Tipul de asociere este cuplul determinat de numarul de instante de entitati care pot fi asociate de o parte si de cealalta a asocierii.
Pentru asocierile binare, tipurile de asociere se stabilesc pornind de la cardinalitati, pe baza urmatoarei reguli.
Fie A o asociere binara legand doua entitati E1 si E2. Fie (x1,y1) si respectiv (x2,y2) cardinalitatile cuplului (E1,A) si (E2,A).
1. daca y1=y2=1, atunci A este de tip 1:1
2. daca y1>1 si y2=1
sau
y1=1 si y2>1 atunci A este de tip 1:n
3. daca y1>1 si y2>1 atunci A este de tip n:m
Exista trei tipuri de asocieri.
Asocierea de tip ,,unu la unu" este asocierea in care unei realizari a entitatii E1 poate sa-i corespunda prin asocierea A cel mult o realizare a entitatii E2, si reciproc, unei realizari din E2 nu poate sa-i corespunda decat cel mult o realizare din entitatea E1.
Asocierea de tip ,,unu la multi" este asocierea in care unei realizari a entitatii E1 pot sa-i corespunda prin asocierea A mai multe realizari ale entitatii E2, dar unei realizari din E2 ii corespunde cel mult o realizare din E1. Acest tip de asociere se mai numeste si asociere de ierarhizare, subordo-narea prin ierarhie putand fi reprezentata grafic printr-o arborescenta.
Asocierea de tip ,,multi la multi" este asocierea in care unei realizari a entitatii E1 pot sa-i corespunda prin asocierea A mai multe realizari din E2, si reciproc. In practica, aceasta asociere se descompune in asocieri de tipul ,,unu la multi", prin introducerea unei entitati intermediare.
dimensiune
Numarul de entitati care participa la o asociere formeaza dimensiunea (gradul) acesteia.
Asocierile pot fi unare (fig. 2.1.a), binare (fig. 2.1.b) si ternare (fig. 2.1.c)
2.3.1.2 Construirea Modelului Conceptual al Datelor
Modelarea este un proces complex si subiectiv, astfel ca solutia aleasa este intotdeauna o varianta perfectibila, imaginea modului in care modelatorul intelege realitatea. Metoda MERISE propune in definirea modelului conceptual al datelor doua tehnici pentru definirea entitatilor si a relatiilor: modelarea prin entitati (modelarea directa) si modelarea prin atribute.
Entitatile si asocierile sunt principalele componente ale modelului conceptual al datelor. Dupa stabilirea lor conform uneia din tehnicile de modelare aleasa, modelul este completat cu restrictiile ce-i asigura corectitudinea in raport cu sistemul real.
1 modelare prin entitati
In cadrul acestei tehnici, entitatile si relatiile sunt identificate direct din rezultatele etapei de proiectare generala, exprimate intr-un limbaj simplu, comun modelatorilor (Univers du discours). Pentru fiecare entitate se determina identificatorul si celelalte atribute. Cardinalitatile si restrictiile se deduc in continuare din context.
PRACTIC, sunt formulate in limbaj simplu, comun, faptele si evenimentele aparute. Substantivele vor da nastere la entitati si verbele la relatii.
Exemplu :
In cadrul activitatii de aprovizionare, facturile sunt emise de furnizori. Facturile contin marfuri. Entitatile si asocierile sunt:
cantitate
2 modelarea prin atribute
In cadrul acestei tehnici se examineaza atributele (proprietati exprimate prin valori) din documentele primare ce contin datele de intrare in sistem, se identifica dependentele functionale dintre ele si se decide cea mai buna cale de a le combina. Din descrierea activitatii desfasurate se stabilesc asocieri intre entitati, se evidentiaza modul de implicare al entitatilor in asocieri.
PRACTIC se parcurg mai multe etape, pe care le prezentam in continuare insotite de un exemplu din sistemul informatic privind acordarea unui credit pentru o firma:
se structureaza sub forma simpla a unor reguli de gestiune rezultatele fazei de proiectare generala.
Exemplu:
n pentru a obtine un credit, o firma trebuie sa depuna la banca o informare privind situatia ei financiara. Aceasta situatie contine, printre altele, valoarea capitalului social si profitul ultimului an.
n decizia de acordare a creditului este urmata de intocmirea unui dosar de credit, care contine informatii privind suma acordata, termenul si dobanda corespunzatoare creditului. O firma, devenita client al bancii, are pentru fiecare credit acordat un dosar de credit.
n pentru creditul acordat, se deschide si se actualizeaza la fiecare rata platita de client, o fisa de credit.
n ratele sunt platite cu documente care, pe langa propriile date de identificare, contin suma platita
se alcatuieste un tabel al atributelor continute in documentele primare .
Exemplu:
DOSAR CEDIT : Numar dosar, Data intocmirii dosarului, Termenul final al creditului, Suma acordata, Dobanda calculata
FISA CREDIT : Numar fisa, Suma totala incasata, Dobanda, Penalitati
DOCUMENT PLATA : Tip document, Numar document, Data document, Suma platita
se construieste dictionarul atributelor, prin eliminarea atributelor calculate si a atributelor sinonime. Se adauga atribute necesare codificarii interne a firmei.
Exemplu:
|
Nr.Crt |
ATRIBUT |
Nr.Crt |
ATRIBUT |
|
CodClient |
NumarDosar |
||
|
DenumireClient |
DataDosar |
||
|
AdresaClient |
TermenFinal |
||
|
CapitalSocial |
SumaCredit |
||
|
ProfitUltimulAn |
DobindaCredit |
||
|
TipDocument |
NumarFisa |
||
|
NumarDocument |
SumaIncasata |
||
|
DataDocument |
Dobanda |
||
|
SumaDocument |
Penalitati |
se stabilesc dependentele functionale intre atribute si se construieste matricea simplificata a dependentelor functionale in care:
liniile sunt reprezentate de determinantii dependentelor functionale
in coloane se inscriu atributele determinate (celelalte atribute din dictionarul atributelor)
in matrice se inscrie cifra 0 la intersectia determinantului (linie) cu atributul determinat (coloana)
Exemplu:
1 1 1
6+7
10 10 10
15 15
Matricea simplificata a dependentelor functionale este:
se creeaza entitati distincte ce contin cate un determinant si atributele determinate de el. In entitati nu se includ atributele care au doi determinanti (atributele cu doua cifre 0 pe coloana). Atributele determinant constituie cheile entitatilor construite.
se stabilesc asocierile si cardinalitatile pe baza regulilor de gestiune si a dictionarului atributelor. Atributele care au doi determinanti, sunt atribute ale asocierii dintre entitatile ale caror identificatori sunt detrminantii respectivi.
fig.2.2
Entitatile, asocierile si cardinalitatile sunt cele din figura 2.2. Am optat pentru entitati distincte CLIENT si SITUATIE FINANCIARA, pentru faptul ca atributele grupate in a doua entitate sunt analizate impreuna in perspectiva acordarii unui credit.
2.3.1.3 Verificare. Normalizare. Descompunere
Indiferent de tehnica de modelare, asupra modelului se aplica operatiile de verificare, normalizare si descompunere:
verificarea presupune asigurarea ca:
numele elementelor ce apar in modelul conceptual al datelor sunt unice.
identificatorii compusi dintr-un grup de atribute trebuie sa nu contina un subgrup in interiorul acestora care sa poata fi folosit ca identificator.
o asociere nu poate exista decat o singura data intre aceleasi realizari de entitati. Daca apar mai multe asocieri, solutia este transformarea asocierii intr-o noua entitate.
atributele derivate, cele ale caror valori se obtin din calcule, nu apar in modelul conceptual al datelor. (exceptie fac situatiile in care acestea prezinta o semnificatie particulara pentru problema studiata, facand parte din restrictii de integritate).
normalizarea este un proces care asigura:
. eliminarea redundantelor fara pierdere de informatie;
. eliminarea anomaliilor in procesul de actualizare.
In cazul entitatilor, normalizarea permite asigurarea ca nu exista atribute repetitive sau compuse intr-o entitate.
Exemplu:
In sistemul informatic privind aprovizionarea cu marfuri, pentru fiecare furnizor exista un atribut care contine informatii despre obiectul aprovizionarii (tipul de marfa, denumirea, cantitatea aprovizionata)
FURNIZOR
CodFiscal
Nume
Marfa
Normalizarea impune definirea unei noi entitati, MARFA, si a unei asocieri aduce, cu atributul cantAprov (canitate aprovizionata)
FURNIZOR aduce MARFA
CodFurnizor 1,n cantAprov 0,n CodMarfa
Nume DenMarfa
In cazul asocierilor, normalizarea permite asigurarea ca atributele unei asocieri depind in totalitate de identificatorii entitatilor participante.
Exemplu:
FACTURI 0,n contin 0,n MATERIALE
NrFactura cantitate CodMaterial
Data pret Denumire
De asemenea in exemplul anterior, cantAprov este atribut care depinde de ambele entitati. El apare ca atribut al asocierii.
descompunerea permite definirea, fara pierdere de informatie, a mai multor relatii de dimensiune doi dintr-o relatie de dimensiune mai mare.
Descompunerea se bazeaza pe dependente functionale si este posibila in urmatoarele conditii:
. exista cel putin o dependenta functionala intre roluri;
. exista o cardinalitatea 0,1 sau 1,1, toate celelalte fiind 0,n sau 1,n.
Descompunerea se face in doua asocieri, una exprimand raportul determinant -- determinat, iar cealalta preluand restul asocierii initiale.
Exemplu:
In cazul:
CONTRIBUABIL DOC PLATA
CodContribuabil 1,n plateste 1,1 NrDoc
Nume DataDocument
Adresa 0,n
TAXE
TipTaxa
Suma
descompunerea este:
CONTRIBUABIL DOC PLATA
CodContribuabil 1,n 1,1 NrDoc
Nume plateste DataDocument
Adresa
1,1
TAXE corespund TipTaxa 1,n
Suma
2.4 Modelarea logica si fizica a datelor
Modelarea logica depinde de particularitatile datelor vehiculate si de posibilitatile oferite de tehnica de calcul a momentului. In [GJ99] se afirma chiar ca "expresia Modelului Conceptual al Datelor in termenii unui anumit tip de solutie informatica constituie Modelul Logic al Datelor".
Prin modelarea logica se urmaresc trei obiective[OD99]:
1. structurarea performanta a datelor prin procesul de normalizare.
2. realizarea unui model al datelor care raspunde cerintelor impuse de formularele si documentele prin care se preiau datele de la utilizator (perspectiva sistemului prin prisma utilizatorului).
3. obtinerea unui model logic al datelor din care sa se poata realiza proiectul bazei de date fizice.
In cazul sistemelor informatice ce vizeaza activitatea economica, volumul mare de date cu care se vehiculeaza este caracterizat printr-o organizare uniforma, constituita din tipuri de inregistrari cu caracteristici asemanatoare, determinate de structura documentelor primare. Operatiile de prelucrare automata au un caracter repetitiv si o frecventa mare de executare. Operatorii sunt simplii si executa in majoritatea cazurilor prelucrari succesive asupra caracteristicilor de acelasi tip. Aceste observatii au condus la alegerea sistemelor relationale drept solutie direct implementabila .
Fata de metodele traditionale care utilizau fisiere strict dependente de aplicatii, bazele de date relationale si sistemele de gestiune corespunzatoare prezinta cateva avantaje care le-au impus in aplicatiile de gestiune. Dintre acestea amintim:
. redundanta minima si controlata a datelor;
. integritate si accesibilitate deosebita la ele;
. posibilitatea introducerii standardelor la nivelul bazelor de date;
. posibilitatea partajarii intre diversi utilizatori.
Modelarea fizica a datelor presupune trecerea de la descrierea logica a datelor la una tehnica, de stocare a datelor. Rezultatele modelarii fizice se concretizeaza intr-un set de specificatii tehnice folosite ulterior de programatorii bazelor de date pentru definirea formatului si structurii datelor stocate in memoria secundara. Studiul tehnic contine formatele sub care vor fi reprezentate atributele, modul de gruparea al acestora din una sau mai multe relatii, in una sau mai multe inregistrari fizice, precum si metodele de accesare a datelor.
Selectarea tehnologiilor folosite pentru stocarea datelor se face tinand cont ca fiecare tehnologie este specifica unei anumite arhitecturi a sistemului.
Descrierea fizica a datelor este legata de sistemul de gestiune al bazelor de date ales pentru crearea bazei de date. Vizeaza modul in care datele vor fi stocate si accesate la nivelul memoriei externe, sistemele care asigura securitatea pastrarii si regasirii datelor.
2.4.1 Trecerea de la modelul Entitate-Asociere la Modelul Relational
Dupa cum am mai afirmat, la nivel logic exista un standard pentru descrierea datelor: Modelul Relational al Datelor. Mai mult exista reguli stricte de obtinere a Modelului Relational al Datelor pornind de la modelul Entitate-Asociere. Respectand aceste standarde, din punctul de vedere al datelor, proiectarea sistemelor informatice se reduce la parcurgerea unor etape clar definite, cu respectarea unor formalisme unanim recunoscute. Este un pas important spre automatizarea trecerii de la conceptie la realizare.
Pentru trecerea de la modelul Entitate-Asociere la Modelul Relational s-au stabilit urmatoarele reguli [UM03]:
fiecarei entitati i se asociaza o schema de relatie compusa din toate atributele entitatii.
2. daca intr-o asociere A exista o entitate E pentru care cardinalitatea maximala a cuplului (E,A) este 1, se adauga la schema de relatie R definita pentru E cheia entitatii ce participa la asocierea A si atributele asocierii.
Exemplu:
Presupunand ca un anume tip de materii prime este aprovizionat de la un furnizor, si ca un furnizor poate furniza mai multe tipuri de materii prime, modelul conceptual al datelor este:
Aplicand regula 1 se creeaza doua scheme de relatie:
R-Furnizori = ( CodFurnizor, Nume, Localitate )
R-MatPrime = ( CodMatPrime, Cantitate, Pret).
Cardinalitatea cuplului (MATERIIPRIME, furnizeaza ) este (1,1).
Aplicand regula 2 avem urmatoarele scheme de relatie:
R-Furnizori = (CodFurnizor, Nume, Localitate )
R-MatPrime = (CodMatPrime, Cantitate, Pret, CodFurnizor)
CodFurnizor de la relatia R-Furnizori este acelasi cu CodFurnizor de la relatia R-MatPrime. Aceasta restrictie se numeste restrictie de integritate referentiala.
daca intr-o asociere A, pentru ambele entitati cardinalitatea maximala este n, se creeaza o noua schema de relatie continand cheile entitatilor ce participa la asociere si atributele asocierii.
Exemplu:
Presupunand ca un acelasi tip de materii prime este aprovizionat de la mai multi furnizori, si ca un furnizor poate furniza mai multe tipuri de materii prime, modelul conceptual al datelor este :
FURNIZORI 1,n 1,n MATPRIME
CodFurnizor furnizeaza CodMatPrime
Nume Cantitate
Localitate Pret
Aplicand regula 1 se creeaza doua scheme de relatie:
R-Furnizori = ( CodFurnizor, Nume, Localitate)
R-MatPrime =(CodMatPrime, Cantitate, Pret)
Aplicand regula 3, se creeaza o noua schema de relatie, ce cuprinde cheile celor doua entitati si atributul asocierii:
R-Furnizeaza = ( CodFurnizor, CodMatPrimel)
2.5 Modelarea conceptuala a prelucrarilor
2.5.1 Caracteristici
proces
Procesul este constituit dintr-o submultime de activitatii independente de structura organizatorica a firmei, care au puncte de intrare si de iesire stabile.
Exemple:
Cerere de credit Comanda acceptata
Acordarea unui credit Gestiunea facturilor
Cerere respinsa Factura emisa
Credit acordat Factura incasata
eveniment
Evenimentul indica faptul ca "ceva" anume s-a intamplat si in consecinta sistemul trebuie sa reactioneze. Este o circumstanta, un semnal adus la cunostinta sistemului si la care acesta trebuie sa raspunda.
Pentru a fi considerat eveniment, semnalul trebuie sa fie perceput de sistem, trebuie sa fie declansatorul posibil al unei activitati.
Exemplu:
Intr-un sistem de evidenta a personalului, faptul ca pentru un angajat se completeaza foaie de pontaj constituie un eveniment, deoarece el declanseaza activitatea de evidenta a salariatilor, dar acest fapt nu constituie un eveniment pentru sistemul informatic de gestiune a clientilor.
In functie de pozitia fata de sistemul informatic, in cadrul modelului conceptual al prelucrarilor se identifica evenimente interne si evenimente externe.
Evenimentele externe provin din exteriorul sistemului studiat si declanseaza in interiorul lui executarea unor activitati. Evenimentele externe nu pot fi controlate, asupra lor neputandu-se interveni.
Exemplu: modificarea cursului leului, modificarea procentului de TVA, modificarea procentului in cazul impozitului pe salarii.
Evenimentele interne survin la incheierea unei operatii din cadrul sistemului studiat si se grupeaza in evenimente rezultat si evenimente intermediare.
Evenimentele rezultat, reprezentate de iesiri ale prelucrarii in cadrul sistemului informatic proiectat, sunt destinate mediului extern al sistemului.
Exemple:
Evenimentele reprezentate de: factura intocmita remisa clientului, ordinul de plata intocmit si depus la banca, declaratia de TVA intocmita si depusa la organul fiscal.
Evenimentele intermediare sunt pe de o parte rezultate din executarea unor operatii si pe de alta parte declanseaza alte operatii in cadrul sistemului.
Exemple:
Intocmirea Notei de Receptie si Constatare de Diferente in urma receptionarii marfurilor, intocmirea Bonului de Consum, a Bonului de Predare-Primire.
Reprezentarea grafica a evenimentelor utilizeaza urmatoarele simboluri:
Ee Ei E
Eveniment Eveniment Eveniment
extern intern rezultat
Evenimente contributive Evenimente emise
(declanseaza actiuni (de sistem)
in cadrul sistemului)
operatia
Operatia reprezinta o secventa continua de activitati producatoare de evenimente. Operatia constituie "un bloc de prelucrare", o succesiune de activitati elementare care se executa neintrerupt din momentul declansarii.
Operatiile sunt declansate de evenimente externe sau de evenimente intermediare si conduc la producerea de evenimente intermediare sau rezultat, in functie de respectarea unor anumite conditii, numite reguli de emisie. Conditiile sunt expresia unor situatii determinate de contextul in care are loc derularea operatiei, cunoscute in momentul derularii operatiei.
sincronizare
O operatie nu se poate declansa decat daca se realizeaza anumite conditii, deci se produc anumite evenimente, numite evenimente contributive. Ansamblul conditiilor care determina declansarea unei operatii este cunoscut sub denumirea de sincronizare. Intr-o maniera generala, sincronizarea se exprima sub forma unei propozitii logice care trebuie sa respecte urmatoarele reguli:
. conditiile trebuie sa priveasca evenimentele declansatoare (contributive)
. conditiile nu trebuie sa se refere la informatia din baza de date;
. trebuie sa existe cel putin o situatie care permit declansarea operatiilor.
Legatura intre evenimente, sincronizare si operatie se reprezinta astfel:
E1 E2 Evenimente
declansatoare
Propozitia logica
numele sincro-
nizarii Sincronizare
Nr. Operatia
Descrierea operatiei Operatia
Reguli de emisie
Ei3 Ei4
Eveniment rezultat Eveniment intern Intermediar
2.5.2 Construirea Modelului Conceptual al Prelucrarilor
In construirea Modelului Conceptual al Prelucrarilor se parcurg urmatoarele etape:
a. delimitarea domeniilor de activitate si a proceselor corespunzatoare. In cazul sistemelor complexe, se analizeaza activitatile desfasurate si se grupeaza in procese care, independent de structura organizatorica, sunt determinate de aceleasi evenimente externe (au puncte de intrare stabile) si au aceeasi finalitate (au puncte de iesire stabile);
b. identificarea evenimentelor si identificarea sincronizarii
Se specifica evenimentele declansatoare si daca este cazul, durata sincronizarii. Se au in vedere conditiile reciproce de determinare a evenimentelor declansatoare, faptul ca trebuie sa existe cel putin o situatie care sa permita declansarea operatiilor.
c. definirea operatiilor. Se analizeaza actiunile si se precizeaza conditiilor de obtinere a rezultatelor, adica se identifica regulile de gestiune care conduc la obtinerea rezultatelor. Se are in vedere ca o operatie este o succesiune neintrerupta de prelucrari, ca in interiorul unei operatii nu se admite producerea unui rezultat intermediar care sa conditioneze derularea operatiei.
Dupa parcurgerea acestor etape se poate trece la prezentarea inlantuirii operatiilor din cadrul fiecarui proces. Se are in vedere faptul ca o operatie este declansata de cel putin un eveniment si ca orice operatie declanseaza la randul ei cel putin un eveniment.
Modelului Conceptual al Prelucrarilor este rezultatul reprezentarii tuturor proceselor identificate in cadrul sistemului real.
pentru sistemul informatic privind acordarea unui credit:
inlantuirea operatiilor si a evenimentelor declansatoare in cazul procesului de avizare a dosarului de credit este prezentata in figura 2.5
inlantuirea operatiilor si a evenimentelor declansatoare in cazul procesului de urmarire a creditului acordat este prezentata in figura 2.6
fig.2.4
fig. 2.5
fig. 2.6
2.6 Modelul Organizational al Prelucrarilor
Modelul Organizational al Prelucrarilor prezinta multimea operatiilor luand in calcul structura organizatorica a firmei si posturile de lucru ce reprezinta unitati de actiune elementare dotate cu mijloace de executie. Postul de lucru este reprezentat prin ansamblul format din echipamentele de prelucrare automata a datelor si persoana ce le utilizeaza.
Modelarea organizationala prezinta prelucrarile din punctul de vedere al utilizatorului, care isi desfasoara activitatea in conditiile concrete ale firmei, ale compartimentelor ei functionale. Inlantuirea procedurilor, descompunerea lor in faze, se face in concordanta cu structura organizatorica a firmei, cu legislatia in vigoare, dar fara a considera o anume solutie informatica de implementare.
2.6.1 Caracteristici
Principalele concepte sunt: procedura, faza, sarcina.
procedura
O procedura este constituita dintr-un ansamblu de prelucrari declansate de unul sau mai multe evenimente externe. Producand unul sau mai multe rezultate, procedura corespunde executarii de catre firma a unui ansamblu de reguli de gestiune.
Exemplu:
. procedura de acordare a creditelor intr-o institutie bancara
. procedura de gestionare a facturilor
faza
Faza este o succesiune neintrerupta de prelucrari, cu aceeasi periodicitate, executate intr-un post de lucru. O succesiune de faze apartinand aceluiasi proces alcatuiesc o procedura.
sarcina
Sarcina este reprezentata de o multime de prelucrari elementare, executate in interiorul unei faze.
2.6.2 Construirea Modelului Organizational al Prelucrarilor
Modelului Organizational al Prelucrarilor se obtine din Modelul Conceptual al Prelucrarilor, luand in calcul structura organizatorica a firmei. Fiecarui proces din Modelul Conceptual al Prelucrarilor ii corespund una sau mai multe proceduri in Modelul Organizational al Prelucrarilor. Pentru fiecare operatie din Modelul Conceptual al Prelucrarilor, in Modelul Organizational al Prelucrarilor corespund una sau mai multe faze.
Cu aceste consideratii, Modelul Organizational al Prelucrarilor pentru un sistem informatic este rezultatul reprezentarilor corespunzatoare tuturor proceselor din Modelul Conceptual al Prelucrarilor
Exemplu
In cazul sistemului informatic de acordare a creditelor, se construieste cate un Model Organizational de Prelucrari pentru fiecare proces delimitat in Modelul Conceptual al Prelucrarilor:
in figura 2.7 este reprezentat Modelul Organizational al Prelucrarilor pentru procesul de intocmire a dosarului de credit
in figura 2.8 este reprezentat Modelul Organizational al Prelucrarilor pentru procesul de avizare a creditului
in figura 2.9 este reprezentat Modelul Organizational al Prelucrarilor pentru procesul de urmarire a creditului acordat
fig. 2.7
Fig.2.8
fig. 2.9
2.7 Descrierea logica si operationala a prelucrarilor
La nivel logic si operational sunt luate in calcul problemele tehnice si restrictiile impuse de mediul de programare existent la nivelul firmei:
. tipul de retea utilizat ;
. particularitatile server-ului si ale posturilor de lucru ;
. SDBD-ul utilizat ;
. sistemul informatic actual, posibilitatile de extindere.
Dezvoltarea rapida a tehnologiei informatiei, libertatea de a alege cea mai buna solutie in functie de context, au limitat definirea unor modele standard de descriere a prelucrarilor la nivel logic si operational. La ora actuala nu exista un formalism unanim recunoscut pentru descrierea prelucrarilor la nivel logic si operational. Exista insa un principiu general, admis momentan de toti proiectantii de sisteme informatice, conform caruia o faza descrisa la nivel organizational se poate descompune in trei tipuri de sarcini, ce vizeaza:
1 prezentarea datelor conform cerintelor utilizatorilor.
2 calcule, actualizari, validari
3 accesul la date
Indiferent de tipul de sarcina, la acest nivel prelucrarile sunt prezentate in legatura directa cu datele. Daca in primul caz accentul cade pe modul de afisare a informatiilor, in ultimele doua cazuri prioritara este reprezentarea interna a datelor, in functie de care se definesc proceduri standard de consultare, actualizare, de citire sau scriere in baza de date.
In primul caz un loc important il ocupa definirea interfetei cu utilizatorul, inserarea unor obiecte vizuale predefinite care sa faciliteze afisarea informatiilor conform unor criterii de selectie stabilite la momentul interogarii.
In cazul al doilea, formulele de calcul, expresie a regulilor de gestiune, sunt aplicate impreuna cu proceduri de control privind respectarea restrictiilor de integritate. Consultarea sau actualizarea bazei de date este precedata de executia unor proceduri ce vizeaza drepturile de acces, care sunt determinate de restrictiile impuse de mediul de programare. Exista proceduri pentru gestionarea drepturilor de acces si proceduri pentru solutionarea eventualelor incidente sau erori aparute la executie.
Pentru toate aceste proceduri, modul concret de implementare depinde de solutia informatica aleasa, de performantele tehnicii de calcul existente si de capacitatea proiectantilor de a alege cele mai bune solutii. In cazul sistemele informatice de gestiune, corespunzator sistemul relational de reprezentare a datelor, pentru manipularea lor se utilizeaza un SGBD relational. Se poate apela si la un limbaj de programare ce ofera facilitati in definirea interfetei cu utilizatorul, in codificarea regulilor de validare sau in efectuarea unor calcule laborioase.
CAPITOLUL III
METODE ORIENTATE OBIECT
3.1 Metodologia orientata obiect
Dezvoltarea sistemelor orientate obiect cuprinde intregul ciclul de viata al sistemului, impartit in trei faze: analiza, proiectare, implementare. In aceste faze se intalnesc, in planuri conceptuale diferite, elemente orientate obiect, notatii din domeniul aplicatiei si al computerelor.
Metodologia orientata obiect presupune construirea unui model al unui domeniu de aplicatie si adaugarea detaliilor de implementare in timpul proiectarii. In faza de analiza se construieste un model pentru abstractizarea aspectelor esentiale din domeniul aplicatiei. Modelul nu cuprinde detalii de implementare. Pentru a descrie si optimiza implementarea, acestea sunt adaugate in etapa de proiectare.
analiza
In faza de analiza, metodologia orientata obiect cere construirea unui model precis, concis si inteligibil al lumii reale, construirea unui model complet al aplicatiei. Analistul descrie ce trebuie sa faca sistemul si nu cum o face, urmareste definirea a ceea ce urmeaza sa realizeze, si nu a algoritmilor care vor fi folositi. Obiectele sunt concepte din domeniul aplicatiei, si nu din domeniul programarii. Atentia este indreptata asupra conceptelor care vor forma nucleul unei solutii ce utilizeaza tehnici orientate obiect.
Analiza este selectiva, neacordandu-se aceeasi importanta tuturor componentelor si insusirilor. Lumea reala se descompune in entitati distincte, se stabilesc legaturile dintre ele si functiile indeplinite. Sunt examinate cerintele, analizate implicatiile, retinute doar aspectele esentiale. Rezultatul este un model cu clase si asocieri eficient prezentate, folosirea acestora facandu-se in partea de proiectare si implementare.
proiectarea
Scopul principal al proiectarii orientate obiect este sa maximizeze posibilitatea reutilizarii claselor in proiecte ulterioare, sa identifice in relatiile de mostenire superclasele care faciliteaza reutilizarea in cadrul aceluiasi proiect.
In "Object-Oriented Modeling and Design" ([R*96]), autorii considera ca proiectarea se efectueaza in doua etape: proiectarea sistemului si proiectarea obiectelor.
Proiectarea sistemului implica impartirea sa in subsisteme, si alocarea resurselor hardware si software.
Proiectarea obiectelor continua strategia aleasa in etapa de proiectare a sistemului si rafineaza detaliile.
Se pastreaza structura claselor stabilita in partea de analiza, luand in considerare minimizarea timpului de executie si folosirea rationala a memoriei.
Operatiile identificate in etapa de analiza sunt exprimate algoritmic, cele complexe sunt descompuse in operatii interne simple. Atributele si asocierile sunt prezentate intr-o forma ce permite ulterior implementare ca structuri de date specifice.
Clasele sunt rearanjate prin evidentierea unor relatii de agregare sau de generalizare, sunt completate cu noi operatii si noi atribute, rezultate din abstractizarea comportamentului comun.
Modelul claselor poate fi rafinat prin introducerea de noi clase, care pastreaza rezultate intermediare de calcul.
Considerand clasele ca niste ,,cutii negre" a caror interfata externa este publica, dar ale caror detalii interne sunt ascunse, proiectantul decide atributele care sunt vizibile din exterior. Ascunderea informatiei interne permite ca implementarea unei clase sa fie modificata, fara a cere clientilor clasei sa-si modifice codul. Este necesara o noua documentare a claselor, pe baza celei din partea de analiza, care sa contina si modificarile care au aparut in faza de proiectare.
Intr-o ultima faza a proiectarii, clasele si asocierile se regrupeaza in module.
implementarea
In timp ce primele doua etape sunt independente de mediul de programare, in aceasta etapa trebuie aleasa solutia informatica pentru realizarea efectiva a sistemului. Clasele si relatiile sunt translatate intr-un limbaj de programare, de regula orientat obiect. In cele mai multe cazuri, scrierea secventelor de cod intr-un limbaj orientat obiect se face aproape automat, pe baza deciziilor luate in fazele anterioare.
Spre deosebire de limbajele procedurale pentru care un program cuprindea o serie de proceduri care se apelau reciproc, procedura reprezentand unitatea de calcul ce transmite valori pentru date sau actualizeaza parametrii de intrare, pentru limbajele orientate obiect exista obiecte capabile sa trimita mesaje de la unul la celalalt, sa proceseze cereri recunoscute ca mesaje, sa raspunda unei colectii predefinite de mesaje care formeaza interfata obiectului. Notiunea de mesaj este o abstractie, care poate fi implementata ca apel de procedura, eveniment discret, intrerupere.
Caracteristicile esentiale ale limbajelor de programare orientate obiect au fost definite in anii '70-'80 de scoala Smalltalk si apoi de limbajul C++. In acelasi timp, notiunea de entitate din modelele semantice a fost preluata in modelele orientate obiect, punand insa accentul pe comportamentul datelor, incapsuland in conceptul de obiect atat datele, cat si operatiile posibile asupra lor.
Primele limbaje orientate obiect au fost limbajele folosite pentru rezolvarea problemelor de simulare si au definit notiunea de clasa, ce regrupeaza o structura de date si procedurile necesare pentru manipularea ei. Rand pe rand au fost reluate si amplificate tendintele de uniformizare ale mediului de programare, unde totul se reduce la obiect, au aparut limbaje care ofera functionalitati ale programarii orientate obiect, conservand structurile de control clasice ale limbajelor imperative.
Obtinand o insumare a avantajelor sistemelor de gestiune a bazelor de date, care interogheaza eficient datele, si a limbajelor procedurale care permit calcule complexe, programarea orientata obiect permite abordarea naturala a lumii reale, folosind componente modularizate si eliminand restrictiile impuse de mediul de programare.
3.2 Modelul obiect
Modelul obiect s-a dezvoltat pe baza principiilor preluate din programarea orientata obiect inca de la sfarsitul anilor '60. Implicarea unor date complexe (documente electronice, date in format multimedia), necesitatea definirii unor tipuri de date-utilizator si reutilizarea componentelor existente, sunt doar cateva din realitatile care au impus in proiectarea sistemelor informatice modelele obiect. Elementul central al modelului il constituie obiectul.
3.2.1 Obiecte
Un obiect este o abstractie, un concept, folosit pentru reprezentarea lumii reale si furnizarea unei baze practice pentru implementarea cu ajutorul tehnicii de calcul. Descompunerea sistemului real in obiecte depinde de modelator si de natura concreta a problemei.
Exemple:
persoana IONESCU, produsul CALCULATOR, factura AS-1234 din 12/03/04 sunt obiecte din lumea reala, ce se regasesc in sistemul informatic privind personalul angajat, gestiunii resurselor si respectiv vanzarii de produse.
Caracteristicile unui obiect sunt: identitate, stare, comportament. Si astfel, modelul orientat obiect este o reprezentare directa a realitatii cu ajutorul unor componente elementare cu identitate proprie si caracterizate prin stare si comportament.
Identitatea unui obiect este acea proprietate a obiectului care il distinge de alte obiecte. Obiectul este definit de un identificator intern unic, independent de valoarea sau de adresa de memorie a obiectului. Identificatorul nu este controlat direct de programator si nu se confunda cu diferitele nume utilizate de programator pentru a-l numi.
Identitatea organizeaza obiectele intr-un spatiu manipulat de limbajele orientate obiect. Spatiul obiectelor se construieste pornind de la obiecte de baza. Ca entitati complexe, obiectele sunt constituite din alte obiecte si/sau din valori. Ele sunt create de utilizatori, prin derivare din tipuri de obiecte create anterior, sau printr-o operatie explicita de creare.
Starea este o abstractie a valorilor atributelor si a legaturilor unui obiect. Starea obiectului reprezinta multimea valorilor tuturor atributelor si legaturilor sale la un moment dat. Starea este adesea asociata cu valoarea unui obiect satisfacand anumite conditii.
Exemple:
▪ persoana IONESCU apartinand unui sistem informatic de evidenta a personalului poate fi in starea angajat cu carte de munca sau pensionar, in functie de valorile atributului varsta. Prin raportare la o firma, poate fi in starea angajat sau somer.
▪ factura AS-1234 din 12/03/04 poate fi in starea achitata sau neachitata, stare determinata de factori externi, reprezentati prin incasarea sau nu a contravalorii sale.
Comportamentul este determinat de ansamblul operatiilor pe care obiectul le poate executa. Exprima modul in care un obiect actioneaza si reactioneaza.
Exemple:
▪ pentru persoana IONESCU, operatia afiseaza permite calcularea si afisarea pe ecran a valorii atributului vechime in munca. Prin operatia valoare, se pot calcula retinerile din salariu sau sporurile.
▪ pentru factura AS-1234 din 12/03/04, cu ajutorul operatiilor definite se pot afisa datele de identificare ale furnizorului sau se poate calcula valoarea totala in functie de articolele facturate si de cota tva.
Comportamentul este cel care altereaza starea unui obiect, determina schimbarea starii sale. Corespunzatoare comportamentului global al obiectului, multimea valorilor grupate intr-o stare, specifica raspunsul obiectului la evenimentul primit
3.2.2 Instrumente ale modelului orientat obiect
Pornind de la componentele elementare (obiecte), modelul obiect al sistemului real se obtine folosind instrumente specifice tehnicilor orientate obiect. Acestea sunt: abstractizarea, incapsularea si ierarhizarea.
3.2.2.1 Abstractizare
Abstractizarea este o operatie a gandirii prin care se desprind si se retin caracteristicile si relatiile esentiale ale obiectului cercetat (DEX). In cazul sistemelor reale complexe, prin abstractizare se poate ajunge la modele inteligibile, usor de studiat, ce permit simularea desfasurarii activitatii folosind tehnica de calcul electronica. Caracteristicile selectate difera in functie de scopul urmarit. Pot astfel exista mai multe abstractizari pentru acelasi sistem real.
In cazul tehnicilor orientate obiect, prin abstractizare se evidentiaza caracteristicile esentiale ale unui obiect, cele care-l disting de alte obiecte. Practic, problema se abstractizeaza prin gruparea obiectele in clase. Abstractizarea da putere modelarii si capacitate de generalizare de la cateva cazuri particulare la cazuri similare. Definitiile comune (numele atributelor) sunt memorate o singura data pentru clasa, in loc sa fie memorate pentru fiecare instanta. Operatiile pot fi scrise o singura data si toate obiectele beneficiaza de codul reutilizat.
clase si obiecte
O clasa de obiecte descrie o multime de obiecte cu aceleasi proprietati (atribute), acelasi comportament (operatii) si relatii similare fata de alte obiecte. Fiecare obiect se mai numeste instanta a clasei. In termeni implementationali, fiecare obiect contine un pointer la clasa din care provine, deci are acces la toate caracteristicile clasei sale.
Clasa serveste la definirea si manipularea multimii instantelor, similar relatiilor din bazele de date relationale, si aminteste notiunea de clasa de la modelele semantice, care descrie insa doar structura, nu si comportamentul instantelor.
Spre deosebire de bazele de date relationale, in cazul modelarii orientate obiect nu exista o teorie matematica ce asigura un set standard de operatori. Acestia sunt reprezentati de operatiile definite la nivelul claselor, si pot fi grupati in patru categorii: constructori, destructori, modificatori si selectori.
O clasa este definita prin:
. numele clasei
. atributele, expresie a valorilor diferitelor stari ale instantelor de clasa
. operatiile pentru manipularea instantelor de clase, numite metode. Specificarea metodei poarta numele de semnatura, iar codul care implementeaza operatiile constituie corpul metodei.
Notiunea de clasa este mai mult utilizata de faza de executie, presupunand doua aspecte: generarea de obiecte si stocarea setului de obiecte care reprezinta instantele claselor. Cu ajutorul clasei se descriu obiectele. Obiectul poseda propriile lui valori, lista atributelor si metodele fiind gestionate de clasa.
3.2.2.2 Incapsulare
Incapsularea este un proces de grupare a elementelor unei clase in elemente accesibile din exterior si elemente proprii. Permite separarea aspectului extern, accesibil altor obiecte, de implementarea interna. Ofera posibilitatea de a masca atributele proprii ale unui obiect, precum si modul in care se executa operatiile. Implementarea poate fi astfel schimbata fara a afecta aplicatia.
Fiecarei clase ii este asociata o multime de operatii, care constituie interfata cu utilizatorul, si prin care obiectele acesteia pot fi manipulate. Corespunzator, obiectul este divizat in doua: continut si interfata. Continutul, dat de structura si modul de actiune al operatiilor este cunoscut numai de obiectul insusi, neputand fi accesibil din afara. Interfata, multime a atributelor si operatiilor vizibile din exterior, permite schimbul de mesaje intre obiecte, asigura functionalitatea modelului.
In "Conception orientee objets et application" [BG94], autorul defineste incapsularea ca fiind procesul de compartimentare a elementelor unei abstractii, afirmand chiar ca "prin incapsulare se separa interfata contractuala a unei abstractii de implementarea sa".
In timp ce interfata priveste numai aspectul extern, abstractizare a comportamentului comun al tuturor instantelor clasei, implementarea priveste reprezentarea abstractiei si mecanismul ce realizeaza comportamentul dorit, detaliile pe care utilizatorul nu trebuie sa le cunoasca.
Separarea intre continut si interfata permite claselor sa ascunda detaliile de realizare. Datele incapsulate sunt protejate de accese nedorite, garantandu-se astfel integritatea lor. Un obiect poate evolua in timp fara a afecta restul sistemului. Incapsularea constituie astfel una din premisele de baza ale reutilizarii.
Abordand construirea modelului din diferite puncte de vedere, Grady Booch afirma ca abstractizarea si incapsularea sunt complementare, prima concentrandu-se asupra aspectului extern, cealalta impiedicand sa se vada interiorul, acolo unde comportamentul abstractizarii este implementat. Abstractizare evidentiaza caracteristicile esentiale ale unui obiect, incapsularea serveste la separarea comportamentului esential al unui obiect de implementarea sa. Abstractizarea pune bariere explicite intre diferite abstractii, incapsularea ascunde toate detaliile unui obiect care nu participa la stabilirea legaturilor cu alte obiecte.
3.2.2.3 Ierarhizare
Ierarhizarea este o operatia de ordonare a abstractiilor. Ajuta la identificarea relatiilor intr-o ierarhie, la clarificarea si buna intelegere a problemei.
Agregarea este o relatie de tip parte-intreg, in care obiecte care reprezinta componente ale unui intreg, sunt asociate cu intregul.
Agregarea este o forma de asociere in care exista un obiect agregat, format din componentele sale, componentele fiind vazute ca parte a agregatului. O aceeasi parte poate apartine mai multor agregari. Semantic agregatul este vazut ca un obiect, tratat ca o unitate in multe operatii, desi fizic este format din mai multe obiecte.
Agregarea nu este un concept independent, ci o forma speciala de asociere. Adauga conotatii semantice unor anumite cazuri particulare:
. Daca doua obiecte sunt legate prin relatia parte-intreg, avem agregare.
. Daca obiectele sunt independente, avem asociere.
Generalizarea este o relatie dintre o clasa de baza si una sau mai multe clase derivate ale ei. Atributele si operatiile comune sunt grupate in superclasa, fiind mostenite de clase.
In timp ce in cazul agregarii una din clase are un rol predominant in raport cu celelalte, in cazul generalizarii clasele sunt integral coerente, subclasa aducand eventuale informatii aditionale, specifice.
Agregarea implica doua clase, una fiind parte a celeilalte. Generalizarea este un mijloc de structurare a descrierilor pentru o clasa. Superclasa si clasa specifica proprietatile unui obiect, obiectul fiind instanta a superclasei si instanta a clasei.
Amandoua dau nastere la arbori prin tranzitivitate. Un arbore al agregarii este compus din instante obiect, toate parte al unui obiect compus. Arborele generalizarii este compus din clase care descriu un obiect.
Privite amandoua drept cazuri speciale de asocieri, agregarea este numita "si-relatie", iar generalizarea este numita "sau-relatie".
mostenire
Partajarea atributelor si operatiilor de-a lungul unei ierarhii intre clase si subclase este evidentiata cu ajutorul conceptului de mostenire.
Mostenirea permite constituirea de noi tipuri de obiecte si clase, evitand rescrierea si recodificarea. Noua clasa poate mosteni atat operatii (metode), cat si variabile de instanta (atribute). In primul caz se poate vorbi de partajarea codului intre metode (code sharing), iar in al doilea caz, de partajarea structurii intre atribute (structure sharing). Impreuna furnizeaza o puternica strategie de modelare, un mecanism natural de organizare a informatiei, care prezinta clasele intr-un graf de mostenire ce permite vizualizarea legaturilor dintre ele.
Conceperea unei aplicatii consta in a grupa informatiile generale in clase care sunt apoi specializate din aproape in aproape in subclase cu comportament particular. In faza de implementare, subclasa este autorizata sa redefineasca implementarea.
Exemplu:
in sistemul informatic privind contractarea si vanzarea produselor, documentele pe cere se consemneaza activitatile desfasurate sunt contractul si factura de vanzare. Prin generalizare se poate defini o clasa DOCUMENT, care are drept atribute NumarDocument si DataDocument. Operatiile sunt: CautaData(NrDoc) si StergeDocument(NrDoc). Clasele CONTRACT si FACTURA mostenesc atributele si operatiile clasei DOCUMENT. In plus, clasa CONTRACT are atributele TermenContract si ValoareContract, iar clasa FACTURA are in plus atributul StareFactura.
Mostenirea intre clase poate fi privita sub doua aspecte:
.. structural, cand o clasa are atribute mostenite de la superclasa. Instantele unei clase trebuie sa retina acelasi tip de informatie ca instantele de la supraclasa sa. Metodele din clasa pot manipula variabilele de instanta (atributele) din superclasa fara restrictii.
In cazul in care o clasa are mai multe superclase, atributele unei clase sunt reuniunea atributelor superclaselor sale, plus cele specifice ei.
.. comportamental, cand o clasa are metode mostenite de la superclasa. Comportamentul este specificat in metodele superclasei si in metodele specifice ei. Metodele sunt operatii care pot regasi sau actualiza starea unui obiect. Sunt parte a interfetei ce manipuleaza instantele clasei.
Similar cu aspectul structural, in cazul existentei mai multor superclase, colectia de metode aplicabile instantelor unei clase este reuniunea metodelor definite in superclase, plus cele specifice ei.
Mostenirea poate fi implementata static sau dinamic. Mostenirea statica presupune adaugarea campurilor mostenite. In timp ce executia este rapida neimplicand parcurgerea legaturilor de mostenire, redefinirea unei clase este dificila, implicand actualizarea tuturor subclaselor. Mostenirea dinamica se realizeaza fara copierea campurilor mostenite, si presupune parcurgerea legaturilor de mostenire. Actualizarea este mai usoara, dar executia este mai putin eficienta.
Generalizarea si mostenirea sunt abstractii puternice folosite pentru transmiterea similaritatilor de la o clasa la alta, pastrand totusi diferentele dintre acestea. Sunt tranzitive, traversand un numar arbitrar de nivele. Subclasele mostenesc trasaturile superclasei, dar pot avea propriile lor atribute si operatii.
In timp ce generalizarea se refera la relatia dintre aceeasi clasa si subclasele sale, mostenirea se refera la mecanismul de a transmite atribute si operatii de-a lungul unei relatii de generalizare. In implementare, mostenirea este sinonima cu notiunea de reutilizare a codului. Trasaturile reutilizabile sunt grupate in superclase. Fiecare programator incearca gruparea claselor cu trasaturi comune si folosirea secventelor de cod comune, implementand subclase proprii specifice aplicatiei.
polimorfism
In stransa legatura cu mostenirea, polimorfismul defineste caracteristica unei operatii de a se comporta in mod diferit in functie de clasa de obiecte careia ii apartine. Polimorfismul permite invocarea pentru obiecte de diferite tipuri a operatiilor cu acelasi nume (semnatura), dar semantica si implementare diferita. La primirea mesajului, stabilirea metodei care se aplica se face in mod dinamic, in functie de clasa obiectului in cauza. Instante ale unor clase diferite pot fi adresate uniform, primind aceleasi mesaje, dar manifesta comportamente diferite.
3.3 Diagrame UML
Diagramele UML sunt mijloacele de reprezentare si vizualizare a elementelor de modelare. In acest subcapitol diagramele UML sunt construite cu OBJECTEERING aflat pe Internet la adresa www.objecteering.com.
3.3.1 Diagrama cazurilor de utilizare
Cazurile de utilizare descriu comportamentul unui sistem din punctul de vedere al utilizatorului. Ii permit sa-si structureze cerintele, sa defineasca modul in care va interactiona cu sistemul pentru a obtine rezultatul dorit. Precizeaza limitele sistemului, relatiile dintre sistem si mediu, ceea ce face parte din sistemul de dezvoltat si ceea ce nu face parte din el. Un caz de utilizare este initiat intotdeauna de un actor si exprima o functie a sistemului, declansata ca raspuns.
Functionalitatea completa a sistemului este data de totalitatea cazurilor de utilizare. Diagrama cazurilor de utilizare include actorii si cazurile de utilizare. Fiecare diagrama contine un set complet de evenimente initiate de unul sau mai multi actori si specifica interactiunea care are loc intre actori si sistem. Ca abstractii ale dialogului intre actori si sistem, cazurile de utilizare descriu interactiuni potentiale fara a intra in detaliile fiecarui scenariu. Specifica doar cand se declanseaza evenimentele si ce actiuni determina, fara a cuprinde detalii functionale.
Actorii sunt elementele din sistem care genereaza sau primesc evenimente. Se determina dintre utilizatorii directi ai sistemului, dintre cei care-l interogheaza sau exploateaza. Alaturi de utilizatori, pot fi actori alte sisteme sau chiar un eveniment.
Reprezentare:
Actor participare caz de utilizare
Livrare marfa
Furnizor
Aceeasi persoana poate juca rolul mai multor actori, initiind mai multe cazuri de utilizare.
Exemplu:
gestionarul unui depozit receptioneaza marfa si o inregistreaza in fisa de magazie:
Un caz de utilizare poate avea mai multi actori, fiecare cu rolul sau
Exemplu:
la incheierea unui contract pentru livrarea marfurilor participa clientul si inginerul de vanzari.
UML recunoaste patru categorii de actori:
. actori principali, persoane care utilizeaza functiile principale ale sistemului;
. actori secundari, persoane care efectueaza sarcini administrative sau de intretinere;
. echipamente externe, echipamentele care fac parte din domeniul aplicatiei si care trebuie sa fie utilizate;
. celelalte sisteme, categorie care grupeaza sistemele cu care viitorul sistem trebuie sa interactioneze.
UML defineste trei tipuri de relatii intre actori si cazurile de utilizare:
.. Relatia de comunicare: actorul participa direct la cazul de utilizare;
Exemple:
clientul achita, functionarul comercial receptioneaza marfa
.. Relatia de incluziune: o instanta a cazului de utilizare sursa include si comportamentul descris de un alt caz de utilizare. Acest tip de relatie se foloseste pentru simplificarea diagramei cazurilor de utilizare in situatii complexe.
Exemple
in diagrama cazurilor de utilizare corespunzatoare aprovizionarii cu marfuri (fig 3.1),
cazul de utilizare - Incheie contract - include si cazul de utilizare
- Semneaza contract -
cazul de utilizare - Livrare marfa - include si cazul de utilizare
- Receptioneaza marfa -
cazul de utilizare - Intocmeste Nir- este inclus in cazul de utilizare
- Receptioneaza marfa -
cazul de utilizare -Incheiere contract- definit in sistemul informatic privind aprovizionarea cu marfuri include si cazul de utilizare
-Semnare contract- din acelasi sistem informatic.
.. Relatia de extensie: cazul de utilizare sursa poate fi extins cu comportamentul unui alt caz de utilizare destinatie. Prin relatia de extensie poate fi introdus, sub forma unui caz de utilizare distinct, un nou caz de utilizare.
Exemplu:
in diagrama cazurilor de utilizare corespunzatoare aprovizionarii cu marfuri (fig 3.1 ), cazul de utilizare - Receptioneaza marfa -poate fi extins cu cazul de utilizare - Returneaza marfa-
Descrierea unui caz de utilizare consta in unul sau mai multe "scenarii", numite instante ale cazului de utilizare.
fig. 3.1
In "Proiectarea obiectuala a sistemelor informatice" [ZR02], autorii propun ca descrierea cazurilor de utilizare sa cuprinda:
▪ denumire sau titlu
▪ scop
▪ actori
▪ punct initial
▪ punct final
▪ descriere derulare
▪ rezultat masurabil
Exemplu:
in cazul acordarii unui credit pentru o firma, descrierea cazului de utilizare -Analiza documentatiei depuse- este:
Denumire : Analiza documentatiei depuse
Scop : Calcularea coeficientului de risc
Actori: Inspectorul de credite
Punct initial: Inspectorul de credite solicita documentatia depusa de firma
Punct final: Obtinerea valorii coeficientului de risc
Descriere derulare
. inspectorul de credite solicita documentatia depusa de firma;
. daca firma este un client al bancii se verifica informatiile existente despre client; daca nu, baza de date este actualizata cu datele generale ale clientului;
. din documentatie se selecteaza informatia care contribuie la calcularea coeficientului de risc;
. in cazul unui coeficient de risc ridicat, cererea este respinsa;
. se analizeaza suma ceruta de firma prin comparatie cu posibilitatile bancii de a acorda creditul solicitat;
. daca rezultatul este favorabil (nivel de responsabilitate < 100.000.000) cererea de credit este admisa si inregistrata;
Rezultat masurabil: Cererea de credit este admisa si inregistrata, sau respinsa
Pentru acest caz de utilizare avem diagrama cazului de utilizare in figura 3.2. Obiectele si interactiunile dintre ele sunt prezentate in diagrama de secvente (fig. 3.3), despre care vom vorbi mai tarziu.
fig.3.2
fig. 3.2
fig. 3.3
3.3.2 Diagrama claselor si diagrama obiectelor
Clasa corespunde semantic entitatilor din sistemul real. O clasa desemneaza un grup de obiecte care au proprietati similare (atribute), un comportament comun (operatii), relatii comune cu alte obiecte si o aceeasi semantica.
Obiectele sunt considerate instante ale clasei, fiind construite pornind de la clase, printr-un proces de instantiere. Un obiect are o identitate ce-l distinge de celelalte obiecte si este caracterizat printr-un ansamblu de atribute si un anumit comportament.
Structura statica a sistemului, privita ca ansamblu al claselor de obiecte si al relatiilor dintre clase, este reprezentata cu ajutorul a doua tipuri de diagrame: diagrama claselor si diagrama obiectelor.
Diagrama claselor prezinta structura sistemului dintr-un punct de vedere general. Este un graf in care nodurile sunt clase iar arcele corespund relatiilor intre clase. In stransa legatura cu ea, diagrama obiectelor evidentiaza obiectele si legaturile dintre ele. Diagramele obiectelor prezinta cazuri particulare, faciliteaza intelegerea structurilor de date complexe.
Reprezentarea unei clase presupune specificarea atributelor ce-i definesc structura, a operatiilor ce-i definesc comportamentul si a relatiilor cu celelalte clase.
In UML, o clasa este reprezentata printr-un dreptunghi in care se specifica numele clasei, atributele si operatiile.
Desemnarea obiectelor se face prin nume individuale sau prin nume generice in locul numelor individuale; numele obiectului este subliniat.
401_furnizor : Furnizori
Fiecare atribut poate lua o valoare dintr-un domeniu de definitie specificat in reprezentarea clasei. Implicit, atributele sunt incapsulate in obiecte, interactiunile avand loc numai prin intermediul operatiilor. Nivelul de vizibilitate al fiecarui atribut (privat, protejat si public) se precizeaza in reprezentarile grafice ale claselor cu ajutorul caracterelor -, #, respectiv +.
Operatiile sunt reprezentate impreuna cu numarul, ordinea si tipul argumentelor necesare definirii actiunii lor. In cazul cand operatia este o functie, se specifica si tipul valorii returnate.
Asocierea este o conexiune semantica bidirectionala intre clase. Ea este reprezentata printr-o linie continua intre clasele implicate, de-a lungul careia se scrie numele asocierii. Daca sensul de transmitere a mesajelor este unic, acesta se evidentiaza printr-o sageata de la emitator la receptor.
Daca intre doua clase exista o singura asociere, numele asocierii este suficient pentru a preciza relatia. Atunci cand intre doua clase exista mai multe asocieri, se foloseste notiunea de rol, care exprima felul in care o clasa vede o alta clasa in cadrul unei asocieri. Fiecare rol al unei asocieri evidentiaza ordinul de multiplicitate care arata cate obiecte ale unei clase pot fi legate unui obiect al celeilalte clase.
Dintre proprietatile unei asocieri, multiplicitatea este cel mai des intalnita in diagramele de structura. Este determinata de context si evidentiaza numarul instantelor unei clase ce se pot asocia cu o singura instanta a altei clase. Multiplicitatea restrange numarul de obiecte ce se afla in legatura, de aceea, cand mai multe instante ale unei clase sunt legate la o instanta a clasei asociate se foloseste cazul general (n). In aplicatii cea mai importanta distinctie se face intre multiplicitatea "zero" si multiplicitatea "mai multi".
In diagrama claselor, multiplicitatea se specifica printr-o cifra urmata eventual de semnul "+", printr-un interval sau printr-o succesiune de cifre. Astfel,
inseamna ca o instanta a unei clasei este legata la o singura instanta a clasei asociate;
inseamna ca una sau mai multe instante ale unei clase sunt legate cu o instanta a clasei asociate;
inseamna ca doua pana la cinci instante ale unei clase sunt legate cu o instanta a clasei asociate;
inseamna ca una, doua sau trei instante ale unei clase sunt legate cu o instanta a clasei asociate.
Asocierile pot fi caracterizate prin atribute si pot avea propriile lor operatii. In acest caz se reprezinta ca o clasa, ce are acelasi nume cu asocierea si se conecteaza printr-o linie intrerupta de asociere.
Exemplu:
in cazul in care intr-o societate comerciala se contracteaza produse, pretul unitar si cantitatea depind de produs dar si de conditiile specificate la incheierea contractului. Sunt deci atribute ale asocierii. Reprezentarea clasei asociere este:
contracteaza
Produse Contracte
contracteaza
cantitate
pret unitar
In finalul acestui subcapitol prezentam in figura 2.4 diagrama claselor in cazul sistemului informatic privind aprovizionarea cu marfuri
CContract
NrContract: integer
Cfurnizor contracteaza DataContract: integer contineC MarfaContract
FDenumire: string TermenContract: integer DenumireMfC: string
FLocalitate: string IncarcaContract() ContContract: integer
AdaugaFurnizor() ConsultaContract() PretContract: integer
AfiseazaLocalitate() ValoareContract() ValoareMarfa Contract()
ModificaFurnizor()
corespunde MarfaFactura
livreaza DenumireMfF: string
CFactura CantFactura: integer
NrFactura: integer contineF PretFactura: integer
DataFactura: string ValMarfaFactura()
TvaFactura()
ValFactura()
fig. 3.4
Agregarea si generalizarea, ca forme de asociere prezente in procesul de ierarhizare a claselor, sunt reprezentate in diagramele de structura cu simboluri specifice.
Agregarea, ca relatie de tip "parte-intreg", evidentiaza o asociere intre o clasa cu rol predominant (clasa agregat) si componentele sale (agregate). Relatia de agregare este o relatie intre clasa intregului si clasa unei componente. Unui intreg cu mai multe componente ii corespund mai multe relatii de agregare. Definind apartenenta componentei la intreg se poate specifica si multiplicitatea fiecarei componente fata de intreg. Acest mod de a defini agregarea ii confera statutul de forma speciala a asocierii.
Agregarea este reprezentata printr-un romb plasat la capatul de asociere al clasei agregat.
Exemplu:
in figura 3.4
▪ intre clasa CContract si clasa MarfaContract este o relatie de agregare
▪ intre clasa CFactura si clasa MarfaFactura este o relatie de agregare
Generalizarea, ca relatie intre o clasa si subclasele sale, este prezenta ori de cate ori se semnaleaza de-a lungul unei ierarhii proprietati comune sau operatii ce evidentiaza comportament comun. Este reprezentata printr-un triunghi ce puncteaza spre superclasa.
Exemplu
se considera clasele:
Factura, cu:
atribute: numar factura, data facturii, cota Tva
operatii: IncarcaDate, AfiseazaData, ValoareFactura
Nir, cu :
atribute:numar Nir, data Nir, cod gestiune
operatii:IncarcaDate,AfiseazaData, AfisezGestionar
Se observa ca cele doua clase au atribute si metode comune. Se poate astfel construi o superclasa, Documente, care sa contina atributele si metodele comune, mostenite de subclasele Factura si Nir. (fig. 3.5)
Fi
fig. 3.5
3.3.3 Diagrama de colaborare
Diagrama de colaborare prezinta un grup de obiecte si interactiunile dintre ele. Obiectele si legaturile dintre ele sunt reprezentate ca in diagramele obiect. Mesajele schimbate intre obiecte sunt reprezentate de-a lungul legaturilor. Ordinea de trimitere a diferitelor mesaje este indicata printr-un numar amplasat la inceputul mesajului.
Numele mesajului corespunde unei operatii definite in clasa obiectului destinatar al mesajului, argumentele sale corespunzand parametrilor actuali ai operatiei. Argumentele mesajelor sunt reprezentate in diagrame fie in pseudocod fie in sintaxa limbajului de programare.
De exemplu (fig.3.6), diagrama de colaborare definita pentru a evidentia aprovizionarea cu materiale si pastrarea lor in gestiune este:
Furnizor
1:se
primeste factura
Materiale 3: transfer(BPTR)
2: depozitare (NRCD)
Gestiune
fig. 3.6
Pentru a evidentia declansarea interactiunilor de catre un element extern sistemului, in diagramele de colaborare pot fi cuprinsi actori. Fara a se intra in detaliile obiectelor de interfata cu utilizatorul, in acest caz primul mesaj de interactiune este trimis de actor.
In faza de analiza, diagramele de colaborare urmaresc scenarii definite pornind de la cazurile de utilizare.
Exemplu:
in sistemul informatic privind vanzarea produselor, se poate defini o diagrama de colaborare intre obiectele claselor Clienti, Facturi si DocumenteIncasare, pentru a reprezenta modul in care au fost incasate facturile emise pentru clienti (fig.3.7 )
fig. 3.7
In faza de proiectare, diagrama de colaborare furnizeaza un punct de vedere complet al dinamicii sistemului, evidentiind comportamentul claselor ca raspuns la aparitia unor evenimente, noi operatii si clasele carora le apartin.
Colaborarile definite pentru a urmari anumite cerinte ale utilizatorilor pot conduce la aparitia sau disparitia unor obiecte, la modificarea proprietatilor unui obiect, la actualizarea restrictiilor de integritate sau la modificarea relatiilor dintre obiecte. In cazul in care obiecte apartinand aceleiasi clase participa la colaborari diferite, in functiile de scenarii diferite ale aceluiasi caz de utilizare, se pot specifica impreuna cu mesajele conditii ce aduc detalii suplimentare pentru implementare.
3.3.4 Diagrama de secvente
Diagrama de secvente ilustreaza interactiunile dintre obiecte din punct de vedere temporal. Este intocmita pentru scenarii ale unui caz de utilizare.Arata obiectele si interactiunile dintre ele de-a lungul unui scenariu.
In diagrama de secvente apar obiecte ale caror clase sunt reprezentate in diagrama claselor si intre care au fost definite relatii. Mesajele corespund operatiilor prin care obiectele comunica. Reprezinta apeluri ale operatiilor descrise la nivelul claselor. Pentru fiecare mesaj, in clasa obiectului destinatar trebuie sa existe o operatie corespunzatoare, reactia obiectului la mesajul primit.
Fiecare obiect este reprezentat printr-un dreptunghi in care se inscrie numele.
Linia de viata a obiectului se specifica printr-o bara verticala.
Mesajele sunt reprezentate prin sageti orizontale de la emitator la receptor. Convenind ca timpul se scurge de sus in jos, ordinea de trimitere este data de pozitia pe axa verticala.
Impreuna cu diagramele de colaborare alcatuiesc asa zisele diagrame de interactiune, ce evidentiaza mesajele trimise intre obiecte. In timp ce o diagrama de secvente se construieste pentru un singur scenariu in care pot fi implicate mai multe obiecte, diagramele de colaborare contin un grup restrans de obiecte, ce pot fi implicate in mai multe scenarii.
Exemplu:
in sistemul informatic privind aprovizionarea cu marfuri, succesiunea operatiilor de la formularea unei cereri de marfa si pana la livrarea efectiva a marfii poate fi prezentata in diagrama de secvente din figura 3.8
fig. 3.8
3.3.5 Diagrama de stari
Diagrama schimbarilor de stare descrie comportamentul obiectelor unei clase prin stari si evenimente. Se construieste doar pentru clasele cu comportament interesant dinamic, completand descrierea unui caz de utilizare.
Diagramele de stari modeleaza ciclul de viata al unei singure clase, evidentiind si eventualele evenimente trimise de ea la alta clasa din sistem.
Fiecare obiect este la un moment dat intr-o stare particulara. Starea este definita de valorile atributelor si de legaturile sale cu alte obiecte. Este un raspuns la aparitia unui eveniment extern.
Exemplu:
In sistemul informatic privind gestiunea stocurilor, starea curenta a unui tip de material poate fi: in aprovizionare, depozitat in gestiune, sau in consum la sectie. Este determinata de valoarea atributului document, ce contine numele documentului pe care materialul este consemnat la un moment dat.
Daca documentul este "Nir", clasa Material este asociata cu clasa Gestiune prin asocierea Depozitat in.
Gestiune <Depozitat
in Material
1..* document
In diagrama de stare sunt descrise operatiile ce reprezinta raspuns la evenimente externe clasei. Corespund unor operatii descrise in diagrama claselor, vizibile din afara clasei (publice).
Starea este descrisa printr-un nume care o identifica si o lista de actiuni/activitati ce sunt executate la aparitia unui eveniment. Intr-o diagrama de stare exista o singura stare initiala si una sau mai multe stari finale, determinate de conditiile de aparitie ale evenimentelor.
Tranzitia de stare reprezinta schimbarea starii datorita unui eveniment. Evenimentul corespunde aparitiei unei situatii date in domeniul problemei. El nu are durata. Trecerea dintr-o stare in alta este instantanee, sistemul fiind intotdeauna intr-o stare cunoscuta.
Tranzitia de stare este reprezentata printr-o sageata de la starea sursa la starea destinatie etichetata cu:
▪ numele evenimentului care a generat tranzitia
▪ conditia de aparitie a evenimentului
▪ actiunea ce se executa la aparitia evenimentului
Exemplu:
in sistemul informatic privind aprovizionarea, diagrama de stari pentru o factura este cea din figura 3.9:
acceptare
Sosita Inregistrata
Do: ConsultaFz livrare Do: IncarcaDateFz
: VerificaFz : IncarcaDateFact
[sume OP<ValFact]
In curs de achitare
achitare partiala Do: CalcValFact
:AfisezAchitat
: SumePartiale
[sume OP=ValFact]
Achitata
Do: ListaSume
: AfiseazaData
: SeteazaStare
fig. 3.9
3.3.6 Diagrama de activitati
Diagrama de activitati descrie comportamentul sistemului introducand elemente de implementare. Atasata unui caz de utilizare, ii detaliaza actiunile si procesele corespunzatoare. Atasata unei clase cu comportament dinamic semnificativ, descrie tranzitia de la o stare la alta sau algoritmul de prelucrare al operatiilor.
Foloseste urmatoarele elemente: actiune, tranzitie, decizie.
Actiunea corespunde unei etape in executia unui algoritm. Fiecare operatie, privita ca o inlantuire de actiuni, poate fi detaliata in operatii elementare. Pentru simplificarea diagramelor, actiuni omogene pot fi grupate in subactivitati.
Tranzitia de la o actiune la alta se reprezinta printr-o sageata etichetata eventual cu:
▪ numele evenimentului care determina tranzitia
▪ conditia de aparitie a evenimentului
Decizia indica ramificarea unei tranzitii in functie de indeplinirea unei conditii.
In faza de analiza, diagramele de activitati completeaza descrierea cazurilor de utilizare. Pentru prezentarea derularii actiunilor sunt folositi termeni apropiati utilizatorului.
Exemplu:
▪ diagrama de activitati din figura 3.10 evidentiaza activitatile desfasurate pentru aprovizionarea cu marfa si inregistrarea ei in gestiune. Poate folosi pentru completarea descrierii cazurilor de utilizare din sistemul informatic privind aprovizionarea, sau poate insoti diagrama de secvente din cadrul aceluiasi sistem informatic.
se inregistreaza factura
se verifica marfa
se inregistreaza marfa in Nir se inreg. marfa refuzata
intocmire OP se storneaza factura
fig. 3.10
In faza de proiectare, diagramele de activitati apar atasate unei clase si contin elemente de implementare ale operatiilor descrise in clase. Actiunile pot fi descrise in limbaj natural, in pseudocod sau intr-un limbaj de programare (C++, Visual Basic). Echivalente schemelor logice utilizate in programarea structurata, diagramele de activitati contin structurile fundamentale de programare: liniara, repetitiva sau alternativa.
In cazul unei clase cu comportament dinamic semnificativ, pentru situatia in care modificarile de stare au o determinare interna, rezultata din efectuarea sau incheierea unor operatii, starea este descrisa printr-o lista de actiuni/activitati, ce se executa la aparitia unui eveniment. Tranzitia de la o stare la alta este determinata de incheierea acestor actiuni sau subactivitati (tranzitii interne). In aceste cazuri, diagramele de activitati insotesc diagramele de stare.
EXEMPLU FINAL CAPITOL II
O societate comerciala fabrica componente pentru calculatoare. Una din cele 4 sectii monteaza calculatoarele.
.Compartimentul vanzari primeste zilnic comenzile clientilor. Comenzile cu regim de prioritate pot fi onorate cu o crestere a pretului de vanzare cu 10%. .Clientii care au mai mult de 10 comenzi sunt tratati automat cu prioritate.
.Pentru onorarea comenzilor, sectia de montaj se aprovizeoneaza cu:
. componente fabricate in alte sectii ale societatii;
. componente de la terte societati.
.Comanda finala este transmisa sectiei de montaj, care o finalizeaza dupa receptia componentelor aprovizionate.
.Numarul comenzii finalizate este transmis compartimentului de vanzari. Compartimentul vanzari se ocupa si de facturare.
.Modificari intr-o comanda pot veni si dupa inregistrarea comenzii. Ele pot viza:
.. codul articolelor, (in cazul unor imbunatatiri tehnice survenite in timp)
.. alte caracteristici: intarzieri, cantitatea comandata, etc.
Rezolvare:
Diagrama cazurilor de utilizare este:
Diagrama claselor (care poate fi completata cu attribute si operatii) este:
Descrierea scenariului "Tratarea unei comenzi printr-o diagrama de secvente este
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 3627
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
