| CATEGORII DOCUMENTE |
Tendinta actuala din industria software impune dezvoltarea de sisteme extrem de complexe si in cel mai scurt timp posibil. Se impune cu necesitate adaptarea procesului de dezvoltare a sistemelor informatice la cerintele din ce in ce mai complexe fata de produsele informatice.
In plus, odata cu impunerea pe piata a limbajelor orientate obiect si a mediilor vizuale de programare, au aparut in ultimii ani mai multe propuneri de procese de dezvoltare orientata obiect a sistemelor informatice, ceea ce a introdus inca o picatura de haos in ecuatie.
In aceste conditii, trei dintre cei mai importanti autori din domeniul proiectarii de software orientat obiect - Ivar Jacobson, Grady Booch si James Rumbaugh - au conlucrat pentru realizarea unui limbaj de modelare standard si a unui proces standard de dezvoltare a produselor informatice. Limbajul pus la punct de acestia - UML (Unified Modeling Language) - inregistreaza un mare succes, fiind adoptat ca standard de Object Management Group (OMG), organismul de standardizare pentru comunitatea orientata obiect. Deci, UML nu reprezinta un standard de metodologie de realizare a sistemelor informatice ci un standard de notatii, concepte,simboluri folosite, diagrame utilizate, modele concepute etc.
Aparitia acestui standard reprezinta un mare avantaj daca ne gandim la multitudinea de notatii si metode utilizate pana nu de mult in proiectarea orientata obiect si pe care UML le substituie cu succes. In prezent este suficient ca proiectantii sa cunoasca acest unic sistem de notatii.
UML-ul reprezinta o sinteza a celor mai multe notatii si concepte utilizate in proiectarea orientata obiect. A inceput ca o coroborare a activitatii lui Grady Booch, James Rumbaugh, si Ivar Jacobson, creatorii a trei dintre cele mai cunoscute metodologii orientate obiect.
In 1996 Object Management Group (OMG) a emis o cerere de oferta pentru un model semantic si notatii standard pentru analiza orientata obiect. Versiunea UML 1.0 a fost trimisa ca raspuns la aceasta cerere in ianuarie 1997. Au existat si alte cinci proiecte concurente. In cursul anului 1997 toti cei sase "rivali" s-au unit si au prezentat o versiune revizuita organizatiei OMG, cunoscuta ca UML versiunea 1.1. Acest document a fost aprobat de OMG in noiembrie 1997 sub denumirea OMG UML versiunea 1.1.
UML propune notatii standard si semantica corespunzatoare pentru modelarea sistemelor orientate obiect. Inainte de aceasta un proiect orientat obiect putea fi descris utilizand una dintre zecile de metodologii disponibile, ceea ce facea ca in cazul unei revizuiri cei responsabili de aceasta sa piarda mult timp cu analiza notatiilor si semanticii metodologiei inainte de a patrunde logica proiectarii. In acest moment, utilizand UML, diferiti proiectanti ce lucreaza la diverse sisteme pot intelege cu usurinta munca celuilalt.
UML-ul prescrie un set standard de diagrame si notatii pentru analiza si proiectarea orientata obiect a diverselor tipuri de sisteme (sisteme software, sisteme hardware sau organizatii), descriind totodata si semantica acestor diagrame si simboluri.
Limbajul unificat de modelare ofera pentru aceasta zece tipuri de diagrame ce pot fi grupate astfel:
Diagrame pentru modelarea proceselor de afaceri, respectiv:
Diagrama cazurilor de utilizare - in cazul metodologiilor orientate pe cazuri de utilizare, aceasta diagrama dirijeaza intreg procesul de dezvoltare al sistemului
Diagrame pentru modelarea structurii statice, respectiv:
Diagrama claselor - pentru modelarea structurii statice a claselor sistemului
Diagrama obiectelor - pentru modelarea structurii statice a obiectelor sistemului
Diagrame pentru modelarea dinamicii:
Diagrame de interactiune, respectiv:
Diagrama de secventa - pentru modelarea circuitului mesajelor intre obiecte
Diagrama de colaborare - pentru modelarea interactiunilor intre obiecte
Diagrame de comportament, respectiv:
Diagrama de stare - pentru modelarea comportamentului obiectelor din sistem
Diagrama de activitate - pentru modelarea comportamentului cazurilor de utilizare, obiectelor sau operatiilor
Diagrame de implementare, respectiv:
Diagrama componentelor - pentru modelarea componentelor
Diagrama de desfasurare - pentru modelarea distribuirii sistemului
Diagrama pachetelor - mijloc de grupare a elementelor diagramelor in pachete
In figura 7.28. se prezinta grafic aceasta clasificare a diagramelor UML. Mecanismele de extensibilitate incluse permit ca in UML sa poata fi abordate aspecte care nu sunt specificate in standard. Aceste mecanisme permit extinderea notatiilor si semanticii UML.
Stereotipul este cel mai utilizat dintre mecanismele de extensibilitate ale UML-ului. Un stereotip reprezinta un mecanism de calificare din punct de vedere al utilizarii. El se poate aplica oricarui element de modelare, inclusiv claselor, pachetelor, relatiilor de mostenire, etc. De exemplu, o clasa cu stereotipul <<actor>> este o clasa utilizata ca agent extern in modelarea proceselor de afaceri. O clasa sablon (template) este modelata ca o clasa cu stereotipul <<parameterized>>, cu semnificatia ca aceasta cuprinde parametrii.
Exista o sectiune speciala in specificatiile UML care prevede stereotipuri specifice pentru clasele si asocierile utilizate in modelarea proceselor de afaceri. Aceasta prevede stereotipuri ca actor, executant sau entitate pentru o clasa si stereotipuri de genul comunicare simpla sau cale intre sursa si destinatie pentru o asociere.
Un model grafic nu poate descrie decat o anumita parte din comportament, dupa care alte detalii trebuie specificate in cuvinte. De multe ori insa, utilizarea cuvintelor induce ambiguitate. Object Constraint Language (OCL) este standardul UML pentru specificarea detaliilor suplimentare sau precizarea constrangerilor modelului. Dezvoltat in cadrul diviziei de asigurari a IBM ca un limbaj de modelare a proceselor de afaceri, OCL este un limbaj formal usor de utilizat. OCL este mai formal ca un limbaj natural, dar nu la fel de precis ca un limbaj de programare, ceea ce inseamna ca nu poate fi utilizat pentru a descrie logica programului sau pentru controlul fluxurilor. Cum acesta este un limbaj destinat expresiilor, frazele sale nu au efecte secundare, ele furnizeaza pur si simplu o valoare fara a schimba starea sistemului.
O tehnica extrem de utilizata pentru a deslusi functionarea modelului orientat obiect este analiza orientata pe responsabilitati cu fise CRC (CRC cards - Class Responsibility and Collaborator cards). Cu ajutorul acestei tehnici clasele identificate in cursul etapei de analiza sunt analizate si selectate pentru a obtine doar clasele cu adevarat necesare pentru modelarea sistemului.
Desi bazele de date orientate obiect devin din ce in ce mai populare, bazele de date relationale raman modalitatea curenta de stocare a datelor. Diagrama claselor poate fi utilizata pentru a modela baza de date relationala pe care se bazeaza sistemul, cu toate astea tehnicile traditionale de proiectare a bazelor de date relationale cuprind mai multa informatie si sunt mult mai nimerite pentru astfel de sarcini. Aceasta lucrare propune modelul entitate asociere (Entity Relationship - ER) ca extensie a UML-ului pentru proiectarea bazelor de date relationale.
Cu ajutorul acestei diagrame analistul stabileste aria de cuprindere a sistemului. Simbolurile folosite intr-o diagrama a cazurilor de utilizare sunt redate in figura 7.29.
Diagrama cazurilor de utilizare este reprezentarea grafica a cazurilor de utilizare si a actorilor (figura 7.30.) si este adesea insotita de o descriere textuala. Aceasta diagrama documenteaza interactiunile sistemului cu mediul, care pot fi interactiuni cu factorul uman, interactiuni cu alte sisteme si interactiuni intre calculatoare.
Diagrama cazurilor de utilizare furnizeaza un mecanism de colectare a cerintelor de exploatare a sistemului. Ea identifica utilizarile solicitate si comportamentul necesar pentru a sustine aceste utilizari si ajuta la identificarea cerintelor sistemului. Atunci cand este utilizata in legatura cu diagrama claselor determina limita antrenarii unui proiect in solutii dezvoltate concurential, de la sumar la descrieri detaliate, care sunt apoi transformate in scenarii de cazuri de utilizare multiple.
Un scenariu de caz de utilizare este o instanta a unui caz de utilizare, asa cum un obiect este instanta a unei clase. O diagrama a unui caz de utilizare nu reprezinta un scenariu de caz de utilizare cu un element model, adica o reprezentare grafica. Un scenariu de caz de utilizare este alcatuit din informatii text care detaliaza evenimentele si raspunsurile la acele evenimente pentru a satisface cazul de utilizare. Fiecare scenariu de caz de utilizare furnizeaza o legatura vitala pentru intelegerea solutiei de afaceri si a solutiilor tehnice posibile care o sustin.
Fiecare diagrama a cazurilor de utilizare are cel putin un caz si un actor. Un caz de utilizare reprezinta secventa actiunilor pe care sistemul le realizeaza pentru a produce ceva de valoare pentru actorul care interactioneaza cu sistemul. Cu alte cuvinte, un caz de utilizare poate fi privit ca un serviciu, o utilitate sau functionalitate oferita de un sistem, subsistem sau de o componenta a acstuia unui utilizator oarecare. Intr-o astfel de situatie, multitudinea serviciilor sau functiunilor oferite de sistem utilizatorilor definesc functionalitatea acelui sistem. Actorul / utilizatorul poate fi o persoana sau un alt sistem extern. Un actor poate participa la mai mult de un caz si, invers, la acelasi caz de utilizare pot participa mai multi actori.
Entitatea ofertanta de servicii privita ca sistem, subsistem sau o componenta a acestuia pentru utilizatori apare ca o cutie neagra, in sensul ca nu este nevoie ca ei sa cunoasca ce contine sau cum este organizata acea entitate. Utilizatorii trebuie sa cunoasca doar ce servicii ii poate oferi acea entitate. Exemplu, utilizatorii finali ai unui sistem informatic trebuie sa cunoasca doar ceea ce le poate oferi sistemul, cum ar fi: elaborarea si editarea balantei de verificare, bilantul contabil, rulajul intrarilor, rulajul iesirilor etc. si nu cum sunt organizate datele in cadrul sistemului, metodele de acces folosite etc. Alte exemple si mai simple ar putea fi cele referitoare la seviciile oferite de un Bancomat (eliberare de numerar, consultare sold cont, efectuare de plati, alimentarea bancomatului cu numerar etc.) sau un Automat de vanzare de bilete de calatorie pentru transporturi feroviare, redat in figura 7.31.
In ambele cazuri utilizatorii nu sunt interesati sa cunoasca organizarea fizica interna a celor doua aparate ci doar serviciile posibile oferite de ele.
O diagrama a cazurilor de utilizare poate contine trei tipuri de asocieri/relatii si anume:
asocieri de comunicare (<<communicate>>, <<comunica>>);
asocieri de utilizare (<<uses>>, <<utilizeaza>>) sau in UML incluziune << include>>;
asocieri de extindere(<<extends>>, <<extinde>>).
O asociere de comunicare arata care actor participa intr-un caz de utilizare. Este tipul implicit de asociere astfel incat nu este obligatorie precizarea acestuia prin stereotipul <<comunicate>>.
Asocierea de utilizare arata ca un caz de utilizare trebuie sa includa comportamentul altui caz de utilizare. Cu ajutorul stereotipului <<uses>> se evidentiaza un comportament obligatoriu, uneori impartasit in comun de mai multe cazuri de utilizare.
Asocierea de extindere arata ca un caz de utilizare poate include optional, in anumite conditii, un alt caz de utilizare (de extindere) si arata dependenta dintre ele.
Fig. 7.31. Sistem automat de cumparare bilete
Diagrama claselor este cea mai importanta diagrama in cadrul analizei si proiectarii orientate obiect. Scopul diagramei claselor este de a structura natura statica a claselor in termeni de atribute, operatii si asocieri (figura 7.32). Majoritatea instrumentelor de modelare orientate obiect genereaza codul sursa numai din diagrama claselor.
Celelalte diagrame UML furnizeaza diferite puncte de vedere din care sa fie identificate atributele, operatiile si asocierile dintre clase. Ele ajuta la validarea diagramei claselor, putand servi la clarificarea unei probleme specifice pentru o audienta specifica. Celelalte diagrame din UML exista, in principal, pentru a alimenta cresterea si modificarea diagramei claselor, fiecare cu o intentie diferita.
Diagrama claselor contine clase si asocieri intre clase. O clasa este un model pentru obiecte cu structura, comportament si relatii similare. Fiecare clasa are un nume, atribute si operatii. In general numele claselor se scriu cu litere mari.
Proprietatile atributelor definesc datele si pot include:
Vizibilitate (public (+), protejat (#) sau privat (-))
Tip (implementare specifica limbajului tipului de atribut, cum ar fi caracter sau intreg)
Valoare initiala (valoare cu care se initializeaza obiectul)
Sirul de proprietati (valori care se aplica atributului, cum ar fi o serie de numere)
Proprietatile operatiilor definesc comportamentul si pot include:
Vizibilitate (public, protejat sau privat)
Lista parametrilor (elemente transmise operatiei care includ tipul sau propriu si valoarea initiala)
Tipul de rezultat (implementare specifica limbajului tipului de atribut a valorii rezultate dintr-o operatie)
Sirul de proprietati (valori care se aplica argumentului in lista de parametri)
O clasa reprezinta cel mai important bloc (structura) dintr-un sistem orientat obiect. Si totusi, in UML clasele sunt doar un tip de clasificatori - denumire data mai multor structuri (blocuri) UML. Un clasificator este un mecanism care descrie caracteristicile structurale si functionale (comportamentale). Clasificatorii includ clase, interfete, tipuri de date, semnale(signal), componente, noduri, cazuri de utilizare si subsisteme.
O clasa este o descriere a unui set de obiecte care au aceleasi atribute, operatii, relatii si semantica. UML mai are si alti clasificatori in afara de clase si anume:
Interfata (interface) - o colectie de operatii care sunt folosite pentru a specifica un serviciu al unei clase sau componente;
Tip de date (data type) - un tip cu valori care nu au o anumita identitate, inclusiv tipurile de date primare (cum ar fi numeric sau string), ca de altfel si enumerarile;
Semnal (signal) - specificatia unui stimul asincron comunicat intre instante;
Componenta (component) - partea fizica si substituibila a unui sistem din care face parte si care asigura realizarea unui set de interfete;
Nod (node) - elementul fizic care exista la executie si care reprezinta o resursa de calcul, de obicei avand memorie si procesor;
Cazuri de utilizare - descrierea unui set de secvente a actiunilor;
Subsistem - un grup de elemente care constituie specificatia comportamentala.
In UML, clasificatorii, deci implicit si clasele, se caracterizeaza prin urmatoarele proprietati: vizibilitatea, scopul si multiplicitatea.
Vizibilitatea unui clasificator este acea caracteristica care specifica daca acesta poate fi folosit sau nu de alti clasificatori.
Exista trei niveluri de vizibilitate in UML:
public (+) - are acces orice alt clasificator;
protected (#) - are acces orice descendent;
private (-) - numai clasificatorul insusi poate folosi aceasta caracteristica.
Scopul determina daca elementul apare in fiecare instanta a clasificatorului sau exista o singura instanta a elementului pentru toate instantele clasificatorului.
In UML, dupa acest scop, se pot specifica doua tipuri de clasificatori:
instance - valori distincte ale elementului pentru fiecare instanta a clasificatorului;
classifier - o singura valoare pentru toate instantele.
In UML se indica faptul ca o clasa este abstracta scriindu-i numele italic. O clasa concreta (normala) este scrisa cu fonturi normale. O clasa care nu are descendenti (o clasa frunza) este specificata scriind leaf sub numele clasei. O clasa care nu are ascendenti se numeste clasa radacina si se specifica scriind root sub numele clasei.
Operatiile au proprietati similare (vizibilitatea si scopul). De obicei o operatie e polimorfa, ceea ce inseamna ca intr-o ierarhie de clase poti specifica operatii cu aceeasi semnatura in puncte diferite din ierarhie. Operatiile din clasele copii supraincarca operatiile din clasele parinte. Operatiile, deci, pot fi: abstracte (ex.: functiile virtuale din C++) si concrete (leaf) - operatia nu poate fi suprascrisa (ex.: operatii nonvirtuale din C++).
Multiplicitatea reprezinta numarul de instante al unei clase. Exista clase:
cu zero instante, este o clasa utilitara care confera doar atribute si operatii;
cu o singura instanta, singleton class
cu un numar dat de instante;
cu multe instante (cazul implicit).
Atragem atentia ca in acest context multiplicitatea are o alta semnificatie fata de aceeasi proprietate aplicata asocierilor .
Multiplicitatea se specifica scriind un numar in coltul dreapta al clasei. Ea se poate aplica si atributelor scriind in paranteze o expresie dupa numele atributului.
In UML sintaxa unui atribut este:
[vizibilitate] nume [multiplicitate] [:tip] [=valoare initiala] [(sir-de-proprietati }]
Exista trei tipuri de proprietati definite pentru atribute:
changeable fara restrictii de modificare;
addOnly pentru atribute cu multiplicitate mai mare ca unu - odata creat nu mai poate fi sters sau modificat;
frozen - valoarea atributului nu poate fi modificata (ex.: constante din C++).
Sintaxa unei operatii in UML este:
[vizibilitate] nume [(lista-parametri)] [:tip-returnat] []
In semnatura unei operatii se pot specifica unul sau mai multi parametrii conform urmatoarei sintaxe:
[directie] nume :tip [=valoare implicita]
Directia poate fi: in (parametru de intrare), out (parametru de iesire), in-out (parametru de intrare care poate fi modificat).
Exista patru proprietati care pot fi folosite pentru operatii:
isQuery, starea sistemului ramane neschimbata;
sequential, trebuie coordonat apelul operatiei astfel incat sa se execute doar una la un moment dat,
guarded, semantica si integritatea obiectu1ui este garantata in prezenta mai multor fluxuri (operatii executate in acelasi timp), este redusa la un ape1 secvential executandu-se cate una pe rand,
concurrent se pot apela de mai multe ori din fluxuri concurente.
Ultimele trei proprietati sunt relevante doar in prezenta obiectelor active, proceselor si fluxurilor de executie (threads).
Clasele template sunt elemente parametrizate (figura 7.33). Rezultatul instantierii unei clase template este o clasa care poate fi folosita ca orice alta clasa.
Figura 7.33 indica modul de scriere in UML a claselor template. Clasele template se pot specifica implicit prin nume sau utilizand bind care arata ca sursa instantiaza template-ul pentru parametrii actuali.
Diagrama obiectelor modeleaza instantele elementelor continute in diagramele de clase. O diagrama obiectuala reprezinta un set de obiecte si relatiile dintre acestea la un anumit moment.
O instanta este o manifestare concreta a unei abstractizari a carui set de operatii poate fi aplicat si care are o stare care arata efectele operatiilor. Instanta si obiectul sunt sinonime. Grafic, o instanta este reprezentata subliniindu-i numele.
Cele mai multe instante modelate cu UML sunt instante ale claselor (si se numesc obiecte), desi exista si instante de componente, noduri, cazuri de utilizare, asocieri. Instantele modelate se plaseaza in diagrame obiectuale.
Operatiile care se fac asupra unui obiect sunt definite in abstractizarea obiectului. in functie de mostenire operatiile pot sau nu fi polimorfe.
Un obiect are o stare care reprezinta proprietatile obiectului (cele statice de obicei) si valorile curente (dinamice) ale acestor proprietati. Aceste proprietati includ atributele obiectului si partile lui agregate. Deci, starea unui obiect este dinamica.
UML defineste doua stereotipuri standard care se aplica relatiilor de dependenta intre obiecte si intre clase:
instanceOf - obiectul "client" este o instanta a clasificatorului "furnizor";
instantiate - clasa "client" creeaza o instanta a clasei "furnizor".
Exista doua stereotipuri relativ la obiectele care se aplica mesaje si tranzitii:
become - clientul este acelasi obiect cu furnizorul, dar la un moment ulterior si cu valori, stari sau roluri diferite;
copy - obiectul client este o carie exacta, dar independenta a obiectului furnizor.
UML defineste restrictii standard care se aplica obiectelor:
tranzient - o instanta a unui rol este creata in timpul executiei, dar e distrusa inaintea terminarii executiei.
Diagramele obiectuale contin obiecte si legaturi. Ca si celelalte diagrame, poate contine note si restrictii. Mai pot contine anumite pachete sau subsisteme, fiecare fiind folosite pentru a grupa elementele modelului.
Aceste diagrame se folosesc pentru modelarea statica a unui sistem, ca diagramele de clase, dar din perspectiva unor instante reale sau prototip.
Scenariile cazurilor de utilizare se dezvolta in mod natural din diagrama de secventa. Diagramele de secventa transforma evenimentele identificate in scenariile cazurilor de utilizare intr-o reprezentare grafica a utilizarilor sistemului de catre actor (figura 7.34). Fiecare eveniment are ca rezultat un mesaj trimis unui obiect cu perspectiva ca acel obiect va realiza o operatie. Rafinarea operatiei si a atributelor utilizate in semnatura operatiei (ca argumente) actualizeaza clasa in diagrama claselor. Identificarea si definirea operatiilor bazate pe evenimente furnizeaza capacitatea de urmarire inapoi la cazul de utilizare.
Diagrama de secventa descrie cronologic interactiunea obiectelor, identificand mesajele schimbate intre obiecte ca raspuns la un eveniment, impreuna cu secventa mesajelor. Intentia este de a stabili limitele contextuale ale scenariului cazurilor de utilizare. Este prima vizualizare a intercomunicarii claselor pentru un anumit scenariu al cazurilor de utilizare. Scopul nu este captarea imediata a operatiilor, ci intelegerea ordinii evenimentelor pentru a parcurge intregul scenariu. Pe masura ce ordonarea devine stabila, un eveniment devine o operatie specifica pe care o initializeaza obiectul receptor.
Diagramele de secventa sunt recomandate pentru realizarea de specificatii in timp real si pentru scenarii complexe. O diagrama de secventa avansata arata, de asemenea, executia conditionala.
Diagrama de secventa listeaza obiectele diagramelor de secventa implicate intr-un scenariu al cazurilor de utilizare in partea superioara de la stanga catre dreapta. Cand se include numele clasei cu numele obiectului, se separa clasa de obiect prin ':'.
Se plaseaza mesajele schimbate intre obiecte, pe verticala de sus in jos. Perioada de existenta se propaga in jos, de la fiecare obiect. Pentru fiecare pas in scenariul cazurilor de utilizare, un obiect trimite mesajul din linia sa de viata catre linia de viata a unui alt obiect. Mesajul contine informatii necesare obiectului doi sa actioneze. Cu alte cuvinte, mesajul declanseaza o actiune in obiectul receptor. Un obiect poate sa fie atat receptor cat si emitator (recursiv). Optional se poate include un actor care sa participe in scenariul cazurilor de utilizare ca fiind un obiect care trimite si primeste mesajele. Un singur pas in timpul scenariului cazurilor de utilizare uneori poate crea sau distruge un obiect. Linia de viata a obiectului se monitorizeaza prin alinierea verticala a obiectului cu pasul sau de instantiere. Se marcheaza cu X sfarsitul liniei de viata, adica pasul in care obiectul este distrus.
Dreptunghiul de-a lungul liniei de viata a obiectului arata durata actiunii, numita activare sau amplificarea controlului, incepand cu mesajul primit si terminand cu mesajul trimis.
Forma diferita a sagetilor reprezinta tipuri diferite ale mesajelor. Mesajul sincron, unde obiectul care l-a trimis asteapta raspunsul de la obiectul care l-a receptionat, este reprezentat prin urmatoarea sageata:
Sageata mesajului de raspuns are aceeasi forma. Cand obiectul care trimite mesajul nu asteapta raspunsul, cazul mesajului asincron, sageata are urmatoarea forma:
Se spune ca procedura are varful de sageata substituit. Mesajul de raspuns nu are nici un varf pe sageata si in schimb are liniuta verticala plasata in apropierea mesajului original trimis. Daca pasii se repeta, mesajele se plaseaza in interiorul unui dreptunghi. Se poate adauga textul iteratiei pentru indicarea numarului de iteratii si a conditiei de iesire. Textul are forma: "[i:=1..n]" cu semnificatia: "repetare folosind variabila i, de la 1 pana la un numar n".
Modeleaza starea dinamica a unui obiect specific. Diagrama de stare consta din stari, actiuni, activitati si tranzitii (figura 7.35).
Diagrama de stare identifica evenimentele care fac tranzitia unui obiect dintr-o stare in alta. Conform UML, o stare este "o conditie sau o situatie din momentul existentei unui obiect care satisface in acel moment anumite conditii, efectueaza anumite activitati sau asteapta anumite evenimente". Diagrama de stare descrie toate operatiile si atributele unei clase in timpul unui eveniment. Diagrama identifica stimulii care declanseaza actiunea. Diagrama include numele starii, oricarei variabile, in timp ce obiectul este in functiune, si evenimentul care declanseaza tranzitia la o noua stare.
Dreptunghiul cu marginile rotunjite reprezinta stari distincte. Orice diagrama de stare include o stare initiala reprezentata printr-un cerc mic de culoare neagra si o stare finala reprezentata prin acelasi cerc dar inclus intr-un cerc putin mai mare. Starea initiala apare la crearea obiectului. Starea finala apare la disparitia obiectului.
Diagrama de stare identifica evenimentele care fac tranzitia unui obiect dintr-o stare in alta. Conform UML, o stare este "o conditie sau o situatie din momentul existentei unui obiect care satisface in acel moment anumite conditii, efectueaza anumite activitati sau asteapta anumite evenimente". Diagrama de stare descrie toate operatiile si atributele unei clase in timpul unui eveniment. Diagrama identifica stimulii care declanseaza actiunea. Diagrama include numele starii, oricarei variabile, in timp ce obiectul este in functiune, si evenimentul care declanseaza tranzitia la o noua stare.
Dreptunghiul cu marginile rotunjite reprezinta stari distincte. Orice diagrama de stare include o stare initiala reprezentata printr-un cerc mic de culoare neagra si o stare finala reprezentata prin acelasi cerc dar inclus intr-un cerc putin mai mare. Starea initiala apare la crearea obiectului. Starea finala apare la disparitia obiectului.
Cu exceptia starii initiale si a celei finale fiecare stare are un nume, atributele proprii unei stari, actiunile si activitatile efectuate. Acestor actiuni si activitati le este atribuit un nume de eveniment, precum si argumente si expresii ale actiunii. Slash-ul 'I', separa expresiile actiunii de la numele evenimentului si argumentele. Actiuni speciale includ:
Entry / intrare - actiune efectuata la intrare intr-o stare
Exit / iesire - actiune efectuata la iesire dintr-o stare
Do / actiune efectuata aflandu-se intr-o stare; evenimentele externe pot intrerupe actiunile Do.
Obiectul tranziteaza dintr-o stare in alta cand apare un eveniment si cand sunt indeplinite anumite conditii. Tranzitia este aratata cu liniute simple de la o stare existenta catre o stare de intrare / tinta. Tranzitia contine:
semnatura unui eveniment care include un nume si argumentele separate de virgule care se afla intre paranteze
o conditie de securitate optionala care interzice tranzitia de stare pana cand nu sunt indeplinite toate conditiile
o actiune introdusa cu slash "/"
In timpul tranzitiei se executa o actiune. Actiunea poate sa fie o operatie efectuata de obiect, un mesaj trimis altui obiect, sau o conditie in cadrul obiectului care declanseaza schimbarea starii. Actiunea insasi poate include o semnatura cand actiunea trimite un mesaj altui obiect. Expresia actiunii poate include obiectul receptor si parametrii transmisi acelui obiect receptor. O sageata reprezinta trimiterea unui mesaj catre un alt obiect. Acest mesaj poate fi trimis de la obiect in timp ce este intr-o anumita stare sau in timpul tranzitiei.
Diagrama de colaborare descrie o examinare non-secventiala a modului in care interactioneaza obiectul. Diagrama de colaborare suporta multiple modalitati de modelare a obiectului. O modalitate arata modul in care obiectele colaboreaza in cadrul unui singur scenariu al cazurilor de utilizare similar cu diagrama de secventa. O interactiune interesanta se produce intre diagramele de secventa si diagramele de colaborare, rezultand operatiuni intensificate si descoperirea unor atribute aditionale. Ambele diagrame furnizeaza puncte de vedere diferite ale aceleiasi informatii. Ambele arata implementarea unui scenariu al cazului de utilizare. Diagrama de colaborare filtreaza timpul sau examinarea secventiala a scenariului pentru a studia asocierile statice si comportamentele dinamice ale obiectelor implicate in interactiune. Avem tendinta sa gandim secvential, dar cateodata, procesele nu sunt atat de procedurale cum ni le imaginam. Utilizarea diagramei de colaborare poate ajuta la clarificarea contextului.
Diagrama de colaborare poate fi utilizata pentru a arata legatura tuturor operatiunilor unei anumite clase. Pentru fiecare operatie, este aratat obiectul tinta al operatiei si orice alt obiect pe care il solicita pentru a implementa operatia. Diagrama de colaborare, astfel, devine un context al tuturor obiectelor si al asocierilor care interactioneaza cu un obiect (figura 7.36).
Deoarece permite focalizarea asupra unei anumite clase, diagrama de colaborare ajuta la rafinarea diagramei claselor, adaugand atribute si operatii. Furnizeaza, de asemenea, informatii cu privire la ceea ce face o clasa atunci cand valideaza codul asociat acesteia.
Notatia UML a diagramei de colaborare este asemanatoare cu diagrama de secventa cu obiecte, mesaje si semnaturi. Fiecare mesaj poate include un numar secvential care sa ordoneze etapele colaborarii. Virgulele separa secventele si se termina cu un slash "/" Un predecesor in numarul secventei indica faptul ca alt mesaj trebuie completat inaintea transmiterii acestui mesaj.
Diagrama de colaborare poate arata un comportament repetat cu un asterisc, "*", urmat de numarul de iteratii si de conditia de iesire incadrata intre paranteze, de exemplu, [i:= 1..n].
O diagrama de activitate permite o mai buna intelegere a operatiilor, in special a celor foarte complexe. Diagramele de activitate permit mai buna intelegere a detaliilor din cadrul unei operatii a unei clase. Diagramele de secventa si de colaborare nu capteaza acest nivel de detaliere suficient de exact pentru ca ele arata doar mesajele schimbate intre obiecte, nu si detaliile asociate acestor obiecte. Alte activitati complexe pot necesita un mai mare rafinament intr-o alta diagrama de activitate care sa arate starile sub-actiunilor si sub-tranzitiile.
Diagrama de activitate este un tip de grafic de stare care specifica activitatea unei anumite clase (figura 7.37).
Diferenta consta in faptul ca un grafic de stare reprezinta intregul obiect, in timp ce o diagrama de activitate reprezinta in mod tipic doar o operatie in cadrul unui obiect. Terminologia diagramei de activitate este usor confundata eu terminologia diagramei de stare intrucat ambele utilizeaza termenul "stari". Starea din cadrul diagramei de activitate este stare a unei actiuni, notiune distincta de stare a obiectului.
Starea actiunii reprezinta starea unei activitati in cadrul unei operatii. Descrie descompunerea starii de actiune si tranzitiile in cadrul unei anumite stari a obiectului, mai mult decat de la o stare la alta. Descompunerea starii nu inseamna ca obiectul isi modifica starea. O actiune a starii reprezinta mai degraba, prelucrarea interna care intervine in timpul actiunii sau activitatii "sursa". Procesarea interna, mai mult decat un eveniment extern, declanseaza tranzitia de la o stare a actiunii la alta. Diagrama de activitate este utilizata pentru a arata aceasta prelucrare interna.
Sa luam, drept exemplu, un automat. Cand consumatorul introduce banii intr-un automat, activitatea de a da consumatorului un produs poate traversa mai multe actiuni de stare. De exemplu, oferirea restului, lasarea produsului sa cada in tava, avansarea liniei de produse. Totusi, nici una dintre aceste stari ale actiunii nu reprezinta stare a obiectului automatului (asteptarea selectiei, livrarea produsului).
Starea actiunii poate fi declansata de :
Completarea unei operatii,
Completarea unei stari, a unei actiuni anterioare sau
Disponibilitatea unui obiect (starea necesara unei actiuni pentru a incepe).
Activitatea consta in etape procedurale sau operatii declansate mai degraba de prelucrarea interna decat de evenimente externe. O stare specifica unui obiect sau completarea uneia din operatiile sale declanseaza o operatie, o actiune in cadrul unei stari a actiunii este deseori ea insasi o operatie. Cand se termina o actiune, poate face un obiect disponibil pentru o actiune urmatoare. Cand se intampla acest lucru, activitatea s-a mutat catre starea sa de actiune urmatoare.
Un dreptunghi cu colturile rotunjite inconjoara actiunea; capetele deschise ale sagetilor indica fluxul controlului. Poate include atributele utilizate de o actiune, dar poate doar sa utilizeze atributele si link-urile obiectului care le detine (de exemplu, obiectul pentru care se defineste activitatea).
O diagrama de activitate poate avea ramuri de control comune sau separate. Aceste fluxuri de actiune au drept eticheta conditia care declanseaza fluxul. Un diamant deschis furnizeaza notatia pentru o decizie in care fluxurile multiple de control ale actiunilor diferite eticheteaza conditiile deciziei.
Diagrama componentelor aduna informatiile din diagrama claselor pentru a crea componente. Diagrama componentelor modeleaza dependenta componentei software in functie de codul sursa, codul binar si componentele executabile (figura 7.38).
Notatia UML pentru componente este dreptunghiul cu doua dreptunghiuri mai mici scoase in afara, pe una din parti. O componenta are un nume si optional un tip separate prin ":". Componenta poate include obiectele pe care le contine.
Un varf de sageata deschis de la o componenta la alta indica o dependenta a sursei de tinta. O relatie de dependenta reprezentata de un cerc deschis si o eticheta de interfata pot fi trasate catre interfata obiectului; aceasta este initierea dependentei. O dependenta poate fi de asemenea trasata direct catre componenta fara trecerea printr-o interfata; aceasta este o dependenta de compilare.
Componentele sunt 'plasate' pe echipamente hardware prin intermediul diagramei de desfasurare. Diagrama de desfasurare modeleaza procesoare si echipamente fizice, securitatea si componentele care sunt plasate pe procesoarele fizice (figura 7.39).
Diagrama de desfasurare reprezinta partitionarea componentelor si a obiectelor active (de exemplu, o baza de date) pe locatia lor fizica. Acest tip de diagrama detaliaza locul de amplasare a componentelor in cadrul infrastructurii sistemului. Cel mai adesea sunt definite mai multe diagrame de desfasurare independente.
Diagrama de desfasurare utilizeaza noduri pentru a reprezenta procesoare si echipamente. Fiecare nod are un nume si, optional, un tip, separate de doua puncte, ":".
O linie continua de la un nod la altul indica faptul ca nodurile comunica, de exemplu, printr-un canal sau o retea. Un varf de sageata deschis indica faptul ca o componenta comunica cu un obiect activ.
UML furnizeaza mijloace de grupare a elementelor din cadrul diagramelor, numite pachete. Intr-un pachet pot fi ambalate alte pachete, clase, cazuri de utilizare, colaborari etc. Un pachet arata doar structurile pe care le contine (figura 7.40).
Un pachet nu arata comportamentul elementelor sale. Un element de modelare apartine unui singur pachet, dar alte pachete pot consulta acest element. Daca se arata explicit continutul pachetului, atunci numele pachetului se trece pe eticheta. Un pachet este un mecanism destinat unor scopuri generale, care organizeaza elementele in grupuri. Fiecare pachet are un nume care poate fi simplu sau cu cale (path name). De exemplu: nume simplu -client nume cale -senzori :: viziuni
Un pachet poate contine clase, interfete, componente, noduri, colaborari, cazuri de utilizare, diagrame si chiar alte pachete. "A contine" este o relatie compusa, ceea ce inseamna ca fiecare element este declarat in pachet. Din punct de vedere al vizibilitatii, pachetele se comporta precum clasele.
Importul unui pachet - Presupunem ca avem clasa A in pachetul A si clasa B in pachetul B. Fiecare sunt elemente publice ale pachetului sau. Daca pachetul A importa pachetul B, A poate vedea B, dar B nu poate vedea A. Importul acorda o permisiune eu un singur sens elementelor unei clase asupra elementelor altei clase.
Exista doua tipuri de relatii intre pachete: importul si dependentele acces, folosite pentru a importa intr-un pachet elementele exportate de altul si generalizarile, folosite pentru a specifica familii de pachete. Un pachet specializat poate fi folosit oriunde este folosit un pachet.
UML defineste cinci stereotipuri care se aplica pachetelor:
facade - un pachet care este doar o vizualizare a altui pachet;
framework - un pachet care contine in principal modele (patterns);
stub - este un proxy pentru continutul public al altui pachet;
subsystem - un pachet ce reprezinta o parte independenta a sistemului modelat;
system - un pachet ce reprezinta tot sistemul modelat.
Pe parcursul ciclului de viata al unui sistem informatic diagramele UML interactioneaza intre ele sau cu alte modele (modelul entitate asociere), figura 7.41.
Cazurile de utilizare si diagramele de interactiune. Toate procesele care trebuie executate de sistem se regasesc intr-un caz de utilizare. Procesele sunt descrise apoi textual sau printr-o succesiune de pasi. Pentru modelarea grafica a scenariilor poate fi utilizata diagrama de activitate. Odata ce comportamentul sistemului a fost astfel surprins, cazurile de utilizare sunt mai departe analizate pentru a identifica cum interactioneaza obiectele pentru a modela acest comportament. Diagramele de secventa si de colaborare sunt utilizate pentru a modela aceasta interactiune intre obiecte.
Clasele, obiectele si diagramele de implementare. Pe masura ce sunt identificate obiectele, acestea pot fi grupate si clasificate in cadrul diagramei claselor si a obiectelor. Diagrama claselor devine astfel elementul central al procesului de proiectare orientat obiect, fiind diagrama care descrie structura statica a sistemului. Diagrama claselor poate fi impartita pe trei straturi care sa evidentieze clasele ce descriu interfata cu utilizatorul (business layer), clasele responsabile de logica aplicatiei (application layer) si clasele pentru stocarea datelor (data layer). Diagrama componentelor este utilizata pentru a grupa clasele in componente sau module. Distribuirea fizica in ansamblul sistemului este modelata cu ajutorul diagramei de desfasurare.
Fise CRC - o extensie informala a UML-ului. Ca extensie a UML-ului, tehnica fiselor CRC poate fi utilizata pentru a supune sistemul analizei orientate pe responsabilitati. Clasele sunt analizate, selectate si rafinate pe baza responsabilitatilor lor in cadrul sistemului si a claselor cu care acestea trebuie sa colaboreze pentru a-si indeplini aceste responsabilitati.
Diagramele de stare. Cu ajutorul diagramelor de stare se modeleaza comportamentul in timp real al fiecarei clase cu un comportament semnificativ dinamic. Diagrama de activitate poate fi si ea folosita, de aceasta data ca extensie a diagramei de stare, pentru a detalia actiunile de raspuns ale obiectelor la evenimente interne acestora. Diagrama de activitate poate fi utilizata si pentru a reprezenta grafic actiunile metodelor claselor.
Implementarea proiectarii (realizarea sistemului). Realizarea sistemului presupune transformarea informatiei cuprinsa in mai multe modele UML in cod si structura a bazei de date. In cazul unui sistem de mari dimensiuni este extrem de utila descompunerea acestuia in trei subsisteme: subsistemul afacerii, care include si elementele de interfata cu utilizatorul (business layer), subsistemul aplicatiei, care include obiectele de implementare a functionalitatii sistemului (application layer) si subsistemul datelor, care include structura bazei de date si obiectele de acces la aceasta structura (data layer).
Implementarea aplicatiei (codificarea). Diagrama claselor este utilizata pentru a genera scheletul aplicatiei in limbajul de programare ales cu ajutorul unui CASE. Diagramele de interactiune, de stare si de activitate furnizeaza informatii suplimentare pentru detalierea partii procedurale a codului.
Proiectarea bazei de date. Stratul datelor (data layer) din diagrama claselor poate fi utilizat pentru a proiecta direct o baza de date orientata obiect sau pentru a construi corespunzator un model entitate asociere (ER - Entity Relationship) pentru o analiza mai detaliata a relatiilor. Pe baza modelului entitate asociere se poate construi apoi modelul fizic al bazei de date relationale.
Testarea cerintelor. Diagrama cazurilor de utilizare este folosita si pentru a testa daca sistemul raspunde cerintelor initiale. Se parcurg toate cazurile de utilizare pentru a vedea daca sistemul corespunde cerintelor clientului.
Desi nu garanteaza succesul unui proiect informatic, UML poate contribui la reducerea costurilor de instruire si schimbare a instrumentelor de lucru atunci cand se face trecerea de la un proiect la altul sau de la o organizatie la alta. UML ofera o baza pentru integrarea instrumentelor, proceselor si domeniilor. In primul rand, UML asigura o terminologie unica si permite realizatorilor de sisteme sa se concentreze asupra obiectivelor proiectelor si nu asupra instrumentelor de modelare.
Asa cum a fost precizat in documentul UML Summary, Version 1.1, elaborat la 1 septembrie 1997 de Rational Software si ceilalti realizatori, scopurile pentru care a fost creat UML sunt urmatoarele:
sa puna la dispozitia utilizatorilor un limbaj de modelare vizual usor de folosit, expresiv. Este foarte important ca standardul pentru analiza si proiectare sa suporte un limbaj de modelare care sa fie folosit pentru realizarea de taskuri generale de modelare. Daca standardul ofera numai o descriere de meta-nivel care reclama ajustarea la un anumit set de concepte de modelare, atunci nu se poate realiza schimbul de modele fara pierdere de informatii;
sa asigure extensibilitatea precum si mecanismele de specializare prin care sa fie extinse conceptele de baza;
sa permita formularea de specificatii independente de un anumit limbaj de programare si de procesele de realizare a sistemului;
sa ofere o baza formala pentru intelegerea limbajului de modelare;
sa incurajeze cresterea pietei instrumentelor orientate pe obiecte;
sa suporte concepte, precum: componente, colaborari, cadre;
sa permita diseminarea celor mai bune practici in domeniul realizarii sistemelor software.
UML reuneste conceptele din Booch, OMT si OOSE. Rezultatul il reprezinta un limbaj de modelare posibil de utilizat de catre utilizatorii acestor metode, dar si a altor metode orientate pe obiecte.
In plus, UML extinde posibilitatile oferite de metodele mentionate mai sus. De exemplu, prin utilizarea UML se poate realiza modelarea sistemelor concurente si a celor distribuite.
UML asigura un standard de limbaj, nu si de proces. Desi UML poate fi folosit in cadrul unei metodologii, experienta echipei de proiect si specificitatea domeniului pot reclama utilizarea unor procese specifice. UML asigura un acelasi meta-model, care unifica semantica si o aceeasi notatie, pentru interpretarea acestei semantici. UML promoveaza construirea iterativa si incrementala a sistemelor software dirijata de cazurile de utilizare si centrata pe arhitectura acestor sisteme.
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 4540
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
