Universitatea de Vest Timisoara Facultatea de Economie si de Administrarea a Afacerilor Contabilitate si Sisteme Integrate in Corporatii

Analiza obiectuala a sistemelor informationale ( aplicatie UML )

2011

1

Cuprins : 1. The Unified Modeling Language (UML) ……………..…………………pg.2

2.
3. 4. 5. 6. 7. 8.

Use-case Diagram …………………………………..…………………

pg.5 Class Diagram ……………………………………….….….…………….pg. 8 Action diagram …………………………………………….….………… pg. 12 Collaboration diagram ……………………………………..…………….pg. 14 Sequence Diagram ……………………………………….….………...…pg. 17 Component and Deployment Diagrams ………………………………...pg. 18 Bibliografie ………………………………………………………………..pg. 23

The Unified Modeling Language (UML)
La crearea unui produs software exista patru faze importante dictate de ingineria programarii si anume: analiza (analiza cerintelor clientului), proiectarea (descompunerea in

2

el jucând un rol analog cu proiectul architectural al unei cladiri de mari dimensiuni. construirea si documentarea sistemelor software incluzând atat structura cât şi designul acestora ce poate fi aplicat si in alte domenii cum ar fi afaceri sau alte sisteme non-software. de aceea avem nevoie de o multitudine de viziuni simple ale acestora asfel incat in final sa stapanim complexitatea. In cadrul lucrului la un proiect software sunt implicate mai multe persone. In cadrul fazei de proiectare se construieste de obicei un modul al proiectului la care se lucreaza. care de obicei devin greu de urmarit din pricina formatarii sau a lipsei de organizare a acestora sau chiar a omiterii anumitor detalii despre o anumita componenta (modul). fiecare are atribuţii complementare celorlalţi. implementarea (scrierea efectiva a codului) si testarea. UML este produsul a multi ani de munca a mai multor companii cu renume in lumea IT dintre care amintim Sun Micro Systems .verifică ceea ce s-a creat. proiectanţi de sistem . Folosind un model ce-i responsabili pentru succesul sau esecul unui proiect se pot asigura inca dinainte de inceperea scrierii codului ca : • functionalitatea proiectului va fi corecta si completa • toate necesitatile utilizatorului final vor fi satisfacute • designul programului va satisface cerintele de scalabilitate.execută arhitectura programului aplicaţiei. Principalele astfel de viziuni sau vederi sunt: • Use-case view • Logical view • Component view • Concurrency view • Deployment view Limbajul UML este o tehnica folosita pentru descrierea specificarea si documentarea functiilor unei aplicatii in timpul fazei de design. programatori . Hewlett-Packard Company.totdeauna trebuie să existe cineva cu această funcţie. Activitatea în echipă este puternic interactivă. şefi de proiect . Modelarea este o parte esentiala a unui proiect software. comunicarea dintre membrii personalului cu specialitati diferite facandu-se de obicei prin intermediul formularelor si rapoartelor. SAP sub patronajul si sponsorizarea concernului OMG (Object Management Group fondat in 1989). constructii etc. software. analişti de sistem . Unul din principalele scopuri ale dezvoltatorilor limbajului UML a fost acela de a crea un set de notatii semantice care sa se adreseze tuturor tipurilor de proiecte arhitecturale complexe indiferent de domeniu (industrial. marketing. Se pot distinge mai multe specialitati: utilizatori .execută modulele.module cat mai mici a produsului pentru usurinta implementarii).). Chiar daca UML nu poate garanta succesul unui proiect. specificarea. Oracle Corporation. 3 . UML este un limbaj grafic creat pentru vizualizarea.exploatatorul softului.execută modelul informatic al aplicaţiei. In cadrul operatiunii de modelare se pleaca de la premisa ca sistemele software sunt complexe. ingineri de test . IBM Corporation. robustete. el constituie o unealta foarte importanta reprezentand de fapt o colectie de practici ingineresti care s-au dovedit de succes in modelarea de sisteme mari si complexe. extendabilitate etc.

iar datorita faptului ca obiectele si clasele sunt definite drept concepte fundamentale un model construit in UML va putea fi relativ usor de implementat intr-o serie de limbaje de tip OOP (C++. sistem de operare sau tip de retea. ArgoUml. work flow. Motive pentru care ArgoUml (aparut in1998) se distinge din multitudinea de unelte Case: • ofera mijloacele necesare pt cresterea productivitatii realizarii softurilor de tip OOP • foloseste doar standarde deschise (open standards) ceea ce inseamna in primul rand posibilitatea unei colaborari cu alte aplicatii care folosesc aceste standarde. usor de urmarit si intretinut. noduri. functii de sistem precum si alte lucruri concrete cum ar fi declaratii intr-un anumit limbaj de programare. Uneltele pentru design. Poseidon (Gentleware). Java. activititati. scheme ale bazelor de date si componente software reutilizabile. Fortran. un limbaj de modelare vizual nu a fost creat si nu este in masura sa inlocuiasca un limbaj de programare insa cu ajutorul limbajului UML se poate modela orice tip de aplicatie care ruleaza pe orice combinatie de hardware. Flexibilitatea lui permite modelarea aplicatiilor distribuite ce folosesc orice tip de middleware de pe piata. Din ele se pot distinge: Rational Rose. Modelele si diagramele create au o importanta influenta asura felului in care o anumita problema este abordata si a felului in care o anumita solutie prinde forma. Aceasta este cauza pentru care: • fiecare sistem complex este abordat printr-un set de vederi diferite ale unui model. (o singura vedere nu este suficienta) • fiecare model poate fi reprezentat cu un grad diferit de fidelitate • cele mai bune modele sunt cele inspirate din realitate Este necesara constructia unui model pentru sistemele complexe deoarece mintea umana nu poate acoperi toate detaliile unui astfel de sistem. 4 . cele care ajuta designerii in luarea deciziilor sunt un mijloc important de a creste productivitatea si calitatea designurilor software rezultate. C#). Exista o serie de elemente care descriu clase. Trebuie precizat insa ca limbajul UML se poate folosi si pentru a modela aplicatii nonOOP in limbaje precum Cobol. UML suporta notatii pentru extinderea puterii limbajului de modelare (referirea se face aici la elementele de tip stereotype si constraints). UML are notatii specifice si reguli gramaticale bine precizate pentru construirea modelelor software. Cu cat complexitatea unui sistem creste cu atat creste si importanta folosirii unei bune tehnici de modelare si implicit a unui limbaj riguros de modelare cum este UML. care se gasesc in numar foarte mare si au grade diferite de utilizabilitate. Unified Modelling Language (UML) este un limbaj de modelare si nu o metoda sau un proces. Printre aceste standarde folosite se afla: in primul rand UML-ul. sau Visual Basic . Object Constraint Language (OCL). Astfel au aparut uneletele CASE (Computer Aided Software Engineering). asigurand avantaje semnificante ingineriei software ajutand la construirea de modele rigurase. Prin abstractizare atentia se concentreaza asupra detaliilor semnificante ignorandu-le pe celelalte. El implica si luarea unor decizii complexe care se vor repercuta asupra produsului final. Exista o bogata colectie de elemente notationale grafice suportate de UML. obiecte. Designul software nu este un simplu proces automat de transformare a unei specificatii in alta. Scalable Vector Graphics (SVG). care sa suporte intregul ciclu de dezvoltare software. UML. apoi XML Metadata Interchange (XMI). stari dar exista si elemente grafice care ajuta la modelarea relatiilor intre elementele amintite. componente.UML ofera un model standard de a scrie documentatie de sistem.

3. instante ale acestor clase.. in faza a doua vor fi explorate iar implicatiile lor vor fi evaluate In figura de mai jos sunt prezentate toate diagramele precizate in specificatiile UML: Diagramele UML • • • Class diagrams: descriu clasele. eventual sa-l modifice pana cand vor fi pregatiti sa extinda acel design partial ( “tirania paginii albe” este un efect similar) • design oportunistic: descompunerea ierarhica este o strategie uzuala in designul sistemelor complexe . fiind singura unealta care implementeaza meta-modelul UML exact asa cum a fost specificat • este o aplicatie 100% Java deci se bucura de tote calitatile unui produs Java • este open-source (in plina dezvoltare) In plus ArgoUml a fost inspirat si a tinut cont de cele trei teorii din psihologia cognitiva: • reflection-in-action: designerii unor sisteme complexe nu concep un design in totalitatea sa. package-urile. Use-case diagrams: descriu use cases. functie de efortul mental pe care trebuie sa-l depuna la un moment dat • generare si explorare: in prima faza sunt generate noi idei care mai apoi. proprietatile lor si diferitele relatii care pot aparea intre acestea. ca la class diagrams vor aparea obiecte. Totusi in practica s-a observat ca designerii lucreaza la module alese oarecum oportunistic. Object diagrams: descriu un anumit scenariu.• implementeaza toate specificatiile limbajului UML 1. in loc de clase. De aceea ei trebuie sa construiasca un design partial. actorii implicati (cei care interactioneaza cu sistemul). sa-l evalueze. pus diferitele relatii existente. 5 .

fie prin conceperea unei diagrame de activitate. constructia unui model use-case. De regula se incepe cu usecase-ul cu cele mai multe dependente deoarece alte use-case-uri depind de acesta. iar drept muchii diferite relatii intre aceste elemente. Statechart diagrams: prezinta starile pe care le pot avea obiectele in cadrul unui sistem. deci va face un schimb de informatii cu sistemul (schimba mesaje). o astfel de diagrama este folosita in etapele preliminarii a procesului de design pentru a colecta cererile clientului cu privire la proiect. actori si dependente.• • • • • Sequence diagrams and Collaboration diagrams: descriu secventa de mesaje schimbate de obiecte la run-time. deci ce ar trebui sa faca un nou sistem sau ce face deja un anumit sistem. precum si o documentatie in care sunt descrise acestea. • Actor este o entitate externa (persoana sau echipament) care are un interes in a interactiona cu sistemul. Relatiile sunt de fapt cele mai importante deoarece acestea le sugereaza care dintre use-case-uri sa fie implementat prima data. aceasta descriere fiind independenta de implementare. descrierea use-case-urilor. 6 . Din punct de vedere grafic o diagrama use-case este un graf avand drept noduri actori si usecases. Activity diagrams: prezinta algoritmi sau data-flow. Un model use-case va descrie si va trebui sa surprinda felul in care un actor va folosi un anumit sistem. Un actor reprezinta un rol nu un utilizator individual al sistemului. Dintre use-cases. Asadar un actor reprezinta o clasa nu o instanta avand stereotipul <<actor>> si deci poate avea atat atribute cat si operatii (behaviours). identificarea actorilor si a use-case-urilor. definirea relatiilor dintre use-cases iar in final validarea modelului. Use-case Diagram Un caz de uz (use case) este o tehnica de modelare folosita pentru a descrie functionalitatea unui sistem. Component diagrams: descriu componentele implementate (Ex: source & object files) Deployment diagrams: descriu felul cum componentele sunt repartizate pe diferitele computere. Descrierea use-case-urilor se face fie printr-un text scris. Adesea. S-ar putea spune chiar ca o diagrama use-case descrie ceea ce face un sistem din punctul de vedere al unui observator extern. Asadar. Pentru a crea un model use-case trebuie parcursi mai multi pasi si anume: definirea sistemului. actorii sunt pentru programatori cele mai neimportante elemente ale unei diagrame use-case. reprezentat printr-o diagrama use-case (sau mai multe) se face de obicei dupa lungi discutii intre dezvoltatori si clienti pe baza specificatiilor asupra carora au cazut cu totii de acord. Cel mai important scop al unei diagrame use-case este de a ajuta dezvoltatorii de sisteme software sa vizualizeze cerintele functionale ale unui astfel de sistem sau unitati de sistem.

sau pur si simplu pentru a reda mai multe informatii despre artefactul UML. reprezentand de fapt un caz de folosinta a sistemului. modifice sau depoziteze vre-un tip de informatie in cadrul sistemului? 3. Cu ce alte sisteme va trebui sistemul nostru sa interactioneze?(sistem = alt computer sau alte aplcatii de pe computerul pe care se dezvolta sistemul) 5. Identificarea use-case-urilor ce trebuiesc modelate intr-un sistem se face raspunzand la urmatoarele intrebari: 1. Cine are nevoie de sprijin in realizarea indatoririlor zilnice? (useri) 3.Sterotipii extind vocabularul UML sunt folositi la etichetarea artefactele UML pentru a indica ca acestea apartin unei anumite categorii. Un actor are un nume. Intr-o diagrama actorii pasivi se pot deosebi de cei activi dupa sensul asocierilor. sau actorul trebuie sa anunte ceva sistemului? 4. Munca zilnica a unui actor poate fi simplificata prin adaugarea de functii noi sistemului? Principalele caracteristici ale unui use-case sunt: 1. La fel ca si actorii.Este o referinta catre o locatie dintr-un use-case unde se pot insera secvente din alte use-cases (fiecare extension point are un nume unic in cadrul use-caseului). creeze. Cine are un interes in rezultatele pe care le va produce sistemul? Use cases – Activitati semnificante pentru sistem (nu trebuie sa fie mai multe de 30. aceasta clasa descriind functionalitatea ca un intreg. • Extension Points . proiectul se va sparge in mai multe bucati). Actorul trebuie sa fie anuntat de evenimentele din sistem. Cine va trebui sa intretina. O instanta a unui use-case poarta numele de scenariu. intoarce o valoare catre un actor 3. Identificarea actorilor din cadrul unui sistem se face raspunzand la urmatoarele intrebari: 1. un use-case este o clasa si nu o instanta. este initiat intotdeauna de catre un actor 2. este complet (valoarea finala este produsa) Un use-case trebuie sa aiba un nume care de regula este o fraza care descrie cat mai bine functinalitatea use-case-ului. incluzand posibile alternative. daca se depaseste numarrul. Cine va folosi principalele functionalitati ale unui sistem? (actori primari) 2. iar numele acestuia trebuie sa reflecte rolul actorului. administreze si sa mentina in stare de functionalitate sistemul?(actori secundari) 4. Are nevoie un actor sa citeasca. Relatiile care se pot modela intr-o diagrama use-case sunt: Generalizare – Este o relatie intre un element parinte (mai general) si un element fiu (mai specific) care este perfect compatibil cu elementul parinte adaugand insa si elemente aditionale. Actorii pot fi categorisiti in actori primari si secundari sau in actori activi (cel care initiaza use-case-ul) sau pasivi (doar participa intr-un use-case). Ce vrea un actor de la sistem? Ce anume vrea el sa faca? 2. De fapt un use-case reprezinta o functionalitate completa a unui sistem asa cum este vazuta de catre un actor. 7 . distruga. erori si exceptii care pot sa apara in timpul executiei unui use-case.

Iata principalele multiplicitati folosite: • 0. sau “pentru fiecare X exista un Y (sau mai multi de Y. variabile si recursive. package-uri etc. O asociere are doua capete. O astfel de relatie poate avea un nume si un stereotip.. dar un client poate face oricate comenzi. O relatie de tip extend intre B si A (B. Lipsa unei sageti indica faptul ca comunicarea se face in ambele directii.1 zero sau o instanta • 0.* cel putin o instanta Aggregation. de instante • 1 exact o instanta • 1. agregari variabile (numar variabil dar finit de componente) Ex: liste. Relatiile de generalizare sunt numite cateodata relatii “este un/o” (“O masina este vehicul => generalizarea masinii este un vehicul”) si sunt folosite pt a descrie comportamentul comun al unui anumit numar de elemente. Numarul respectiv poate fi un singur numar sau o serie de numere.. Dependente – Pot exista o serie de dependente semantice intre diferite element ale modelului (si intre use-cases) si are rolul de a sugera ca un element foloseste un alt element. Exista mai multe tipuri de agregari cum ar fi: 1.. intr-o singura directie sau nenavigabile. Urmand sensul dependentei. Associeri: Apar intre diferite elemente (Ex: actori si use-cases) si pot fi navigabile in ambele directii. O asociere poate avea si ea un nume care este de preferinta sa fie ales astfel incat sa descrie cat mai bine in ce consta respectiva asociere. Acestea au de obicei un stereotip pentru o mai buna definire a rolului dependentelor.O asociatie in care un element este “parte” a unui “intreg” reprezentat de celalalt element. De exemplu poate fi un singur client pentru o comanda. prestabilit de componente) 2. O asociere intre doua elemente ar insemna (s-ar traduce) ca elementele aflate intr-o relatie de asociere “stiu una de alta”. o schimbare in specificatia unui element ar putea afecta si pe elementul aflat in relatie de dependenta cu primul. Elementul specializat (fiu) mosteneste comportamentul elementului general (superclasa sau parintele) extinzand intr-un anumit fel acest comportament. “sunt conectate”. Exista doua tipuri speciale de dependente: <<extend>> si <<include>>. agregari fixe (au un nr. In cadrul diagramei use case-urile sunt conectate de actori cu ajutorul asociatiilor. niciodata pentru instante. deci pentru tipuri.Generalizarea este folosita pentru actori. Exemplu de generalizare: un proiect este un proiect intern sau extern. Multiplicitatea unui capat al asociatiei reprezinta numarul posibil de instante asociate cu o singura instanta a celuilalt capat. • Extend relationship – O relatie unidirectionala intre doua use-cases. care arata cine cu cine comunica precum si care este actorul care initializeaza un use-case. In cadrul unei agregari elementul parte mai exista si dupa ce elementul “intreg este distrus”. Ca si la agregare pot fi compozitii fixe. clase. vectori 3. Reprezentarea grafica a unei asociatii este o linie simpla care poate avea si un stereotip. use-cases. agregari recursive Ex: arborii binari contin arbori binari Composition – Este o puternica forma de agregare in care elementul “parte” este distrus automat in momentul distrugerii elementului “intreg”. 8 . A = use-cases) inseamna ca caracteristicile lui B pot fi incluse in A. asta depinzand de multiplicitate)”. deci depinde de acel element.* nici o limitare la nr.

• Include relationship .i. scopul ei principal fiind acela de a descrie structura statica a sistemului care este modelat. Modeland structura statica a claselor. Cand se foloseste programarea orientata pe obiecte pentru realizarea sistemelor software. • Nu trebuie sa existe vre-un actor fara nici o asociere • Daca exista o functionalitate cunoscuta care nu este abordata de vre-un use-case atunci se va crea un nou use-case pt respective functionalitate. Class Diagram Class diagrams sunt probabil cele mai importante diagrame UML. • Daca exista un caz apecial al unui use-case atunci se va folosi o relatie de tip <<extends>>. • Daca exista similaritati intre o serie de use-cases care cum ar fi un flux comun de activitati (eventual folosit in mod repetat) atunci s-ar putea crea un nou use-case care sa fie folosita de catre primele folosind relatia de incluziune (<<uses>>). generalizari etc). clasele si relatiile devin chiar codul insusi. Spunem ca diagramele claselor sunt statice deoarece nu descriu ceea ce se intampla in momentul in care clasele relationate interactioneaza. clasele trebuie sa fie identificate si descrise. clasele. Identificarea claselor o putem face raspunzand la urmatoarele intrebari: • Avem un tip de informatie care trebuie depozitat sau analizat? • Avem sisteme externe inglobate in activitatea sistemului modelat? • Exista dispozitive pe care sistemul trebuie sa le mânuiasca? • Exista biblioteci sau componente din alte proiecte care vor fi folosite in sistem? • Actorii folositi (din use-cases) au un rol in sistem a. In timpul crearii unei diagrame use-case trebuie avute tot timpul in vedere urmatoarele: • Daca exista similaritati intre o serie de actori atunci s-ar putea crea o clasa de baza a acelor actori din care sa derive acestia folosind relatia de generalizare. protected sau private). Pentru a crea o class diagram. In modelarea orientata pe obiecte . inseamna ca caracteristicile lui B vor fi intotdeauna incluse in A .O relatie unidirectionala intre doua use-cases. vor trebui implementati ca fiind clase? Daca se raspunde cu da la una dintre aceste intrebari atunci vom avea un posibil candidat de a fi implementat drept clasa. Clasele sunt cele mai importante concepte in programarea orientata pe obiecte si s-ar putea spune si in limbajul UML. o class-diagram prezinta structura interna a fiecarei clase (atribute. O astfel de relatie intre use-case-urile A si B inseamna ca. Clasele pot fi impartite in clase: • active: cele care initiaza si contoleaza fluxul activitatii 9 . operatii) precum si cel mai important aspect si anume relatiile pe care fiecare dintre clase le are cu celelalte clase (asocieri. stereotipul si vizibilitatea (public. O class diagram arata cum diferitele entitati (persoane. obiectele si relatiile dintre ele sunt principalele elemente pentru modelare. lucruri si date) sunt relationate intre ele. Principalele proprietati ale unei clase sunt: numele.

va trebui neaparat sa implementeze aceste operatii => sa le scrie codul) • concrete: opusul a ceea ce se numeste clasa abstracta In ambele cazuri. Relatiile dintre clase vor fi reprezentate de liniile conectoare. Unele dintre aceste tipuri de relatii sunt deja cunoscute ele aparand si la diagramele de tip use-case. atributele si operatiile. O clasa abstracta va avea numele scrise cu caractere italice. 10 . cand exista o mostenire.• pasive: depoziteaza informatii si servesc celorlaltor clase sau clase • abstracte: nu pot fi instantiate obiecte de tipul acestor clase (folosite pentru mostenire: o clasa care mosteneste o clasa abstracta. un obiect apartinand acestei clase va folosi noul cod al operatiei respective. Figura de mai sus demonstreaza ca o clasa are atat atribute cat si operatii. avand functii abstracte. daca se rescrie codul unei operatii. Notatia UML pentru o clasa este un dreptunghi imparit in trei parti: numele clasei.

char …) sau poate fi o instanta a unei clase construite tot de noi. Un atribut are un tip care poate fi predefinit sau primitiv (integer. Am vazut ca atributele sunt valori care caracterizeaza obiectele clasei. cele afisate in al treilea compartiment al figurii ce reprezinta clasa sunt folosite pentru a manipula atributele sau pentru a performa alte actiuni. Un atribut este folosit pentru a pastra informatii care descriu si identifica o instanta specifica a clasei. Pentru un mai mare grad de abstractizare se poate apasa “Hide all compartments”. si pot fi vazute ca fiind interfata unei clase. Operatiile intr-o clasa descriu ce poate face o clasa. atributele si linkurile ar trebui sa fie automat initializate. cateodata valorile atributelor fiind o cale de a descrie starea obiectului. Java). 11 . Este posibil ca o operatie sa aiba o valoare de tip default pentru un parametru. Signatura descrie tot ce este nevoie pentru a folosi operatia. cel care va corespunde unui constructor dintr-un anumit limbaj de programare (C++. Asadar declaratorii de acces sunt folositi pentru specificarea modului de acces la informatiile incapsulate in clase. Operatiile sunt de obicei numite functii sau metode. In UML un constructor este redat printr-o operatie avand acelasi nume cu clasa care are stereotipul “create”. ceea ce va duce la afisarea clasei sub forma unui mic dreptunghi simplu (nu vor mai fi afisate compartimentele aferente atributelor si operatiilor). private (nu accepta referirea din alte clase) si protected (accepta referirea numai din clasele fiu => protected este folosit impreuna cu o relatie de generalizare sau specializare). O operatie are un tip returnat. Operatiile.Primul compartiment al dreptunghiului clasei si anume numele clasei este de obicei un substantiv care trebuie sa fie derivat din domeniul problemei analizate si de asemenea trebuie sa fie cat mai putin ambiguu posibil. Cuvantul cheie “leaf” pentru o clasa indica faptul ca acea clasa nu este conceputa pentru a avea subclase. tipul returnat. pe cand cuvantul “root” indica faptul ca acea clasa este radacina unui arbore de derivare. Aceasta inseamna ca in cazul in care apelantul operatiei nu specifica un parametru operatia va folosi valoarea default pt acel parametru. Din figura de mai sus se observa ca in cadrul diagramei se pot specifica declaratorii de acces (specifica vizibilitatea) si sunt cei cunoscuti si folositi in mediile de programare OOP. Pentru a performa o operatie. numele si parametrii sunt numite signatura operatiei. Ceea ce trebuie mentionat este faptul ca aceste tipuri primitive nu apartin limbajului UML. byte. dar ele sunt interioare unei clase si deci vor putea fi aplicate numai obiectelor clasei. Acestia sunt public (accepta referirea din alte clase). String. ce servicii ofera. ci unui anumit limbaj de programare setat in cadrul unealtei CASE folosite. Impreuna. (In lista tipurilor ne vor aparea si clasele definite de noi deci unui atribut va putea fi de un astfel de tip). o operatie este aplicata unui obiect al clasei (este numit pe un obiect). real. Cand un obiect (instanta al unei clase) este creat. Pentru acest lucru am putea avea o operatie statica care sa faca acest lucru sau am putea crea un asa-zis constructor. Celelalte compartimente sunt cele corespunzatoare atributelor si operatiilor. un nume si zero sau mai multi parametrii. O operatie avand stereotipul “destroy” este echivalentul unui destructor din C++ si va fi responsabila in eliberara spatiului de memorie alocat obiectelor dinamice.

Relatiile de mostenire – Sunt niste relatii care pot aparea intre interfete sau clase.Atat operatiile cat si atributele pot fi statice (afisate subliniat). sau o sageata orientata in cazul in care asocierea este cunoscuta doar de una dintre clase. Simbolul UML pentru o relatie de mostenire ar fi o linie cu un triunghi alb in capatul dinspre superclasa. Clasa specializata (subclasa) mosteneste atributele. aceste denumiri fiind de fapt rolurile jucate de instante ale clasei in cadrul asocierii. o conexiune semantica intre doua clase. pe cand o operatie statica este folosita cu scopuri generice cum ar fi crearea sau gasirea unui obiect acolo unde un obiect specific nu exista. O relatie de asociere trebuie sa fie o linie simpla daca ambele clase sunt constiente de existenta celeilalte. insa nu si intre interfete si clase. insa intr-o class-diagram mai poate aparea un tip de asociere numita asociere recursiva. (! Priviti codul sursa generat pentru clasele Cerc si Punct pentru o mai buna intelegere a notiunii de asociere). operatiile si chiar si asocierile clasei generale (superclasei). Un atribut static mai poate fi denumit si o variabila a clasei putand fi accesat si fara sa existe vre-o instanta a unei clase. 12 . O clasa poate fi conectata de ea insasi printr-o asociere ca in exemplul de mai jos: Observati in exemplu de mai sus ca asocierea numit “casatorit(a) cu” are cele doua capete denumite “sot” respectiv “sotie”. In UML o asociere este o legatura. Asocierile au mai fost intalnite si la diagramele use-case. deci nu vor apartine unei instante a clasei din care provine ci vor apartine chiar clasei. Principalele tipuri de relatii care se pot gasi intr-o class-diagram sunt: Relatii de asociere: este o legatura intre doua clase (=>este o relatie si dintre obiectele. fiecare dintre instantele clasei avand acces la acestea. instante ale celor doua clase).

avand stereotipul <<imports>>. asa se pot situa si in interiorul package-urilor exprimand astfel interdependentele existente intre anumite package-uri. Asa cum clasele se pot plasa direct intr-un model. unul dependent de cel pe care il vom numi independent. respectiv sa scrie codul acestora. va putea avea si alte operatii proprii. Importarea dintr-un package este vazuta ca o dependenta. O schimbare in elementul independent va afecta si elementul dependent. daca insa importa elemente din alte package-uri vom spune ca avem de-a face cu o shared aggregation. Relatii de tip realization – Relatii care exista doar intre interfete si clase. si bineinteles. Despre clasele care au o legatura cu o interfata vom spune ca implementeaza acea interfeta si ele vor fi nevoite sa implementeze aceste operatii (metode). Asta inseamna ca o clasa va “mosteni” toate operatiile interfetei. Un package prezinta similaritati cu o agregare in sensul ca package-ul isi detine elementele. Operatiile sunt abstracte si nu au nici o implementare in cadrul interfetelor. avand stereotipul <<interface>>. Interfete – sunt un fel de clase restrictionate in a contine doar operatii nu si atribute. Packages – Un package este un mecanism de grupare folosit pentru organizarea elemntelor in grupuri de elemente avand o legatura semantica.Relatii de dependenta – reprezinta o legatura semantica intre doua elemente ale modelului. 13 . Asadar package-urile sunt folosite pt structurarea modelului (un element poate fi continut doar de un singur package). Din punct de vedere grafic o interfata este reprezentata printr-un dreptunghi cu doua compartimente (nume+operatii). iar in cadrul unei class-diagram ele sunt folosite pt specificarea explicit a ierarhiilor.

Guardurile vor fi atasate de tranzitiile care pleaca din punctul de decizie si in mod normal la un moment dat numai unul dintre aceste guarduri trebuie sa aiba valoarea de adevar True. exceptie facand evenimentele. sau asupra triggerelor ce declanseaza activitatea. la fel ca si o diagrama de stari. actiuni care mai tarziu vor f transformate in cod. insa atunci cand acestea lipsesc (de cele mai multe ori) tranzitia va avea loc atunci cand toate activitatile din action-state se vor termina. Notatiile diagramelor de activitate sunt foart asemanatoare cu a celor de stari (statechart diagram). in special in cele dintre doua sau mai multe clase si de a prezenta rezulatele acestor actiuni. cursul activitatii… Exemplu: modelarea unor functionalitati ale unui sistem sau subsistem. organizare. printr-o tranzitie. In functie de aceasta valoare de adevar activitatea va urma un curs sau altul. referirea facandu-se la actori (muncitori).Action diagram Scopul diagramele de activitate este acela de a modela actiunile (munca + activitati) implementate in operatii. Asadar. insa aceste diagrame pot exista si independent de use-cases. Specificatiile UML permit existenta unei singure stari initiala care sa aiba doar o singura tranzitie care conecteaza starea initiala de o alta stare. o diagrama de activitate se concentreaza asupra actiunilor interne ale activitatilor si nu asupra actiunilor care apeleaza activitatea in plin progres. Este posibil insa ca o activity diagram sa aiba mai multe stari finale. diagramele de activitate incep cu un Initial State care este conectat de prima stare. cu alte cuvinte o activitate poate sa se termine in diferite maniere. la fel ca la diagramele statechart. 14 . care sa reprezinte terminarea unei ramuri logice. iar activitatile care termina modelul sunt conectate de un FinalState. Pentru definirea unor astfel de ramuri logice se folosesc punctele de decizie. la un grad de detaliere mai mare. Ele pot avea atasate conditii guard sau actiuni. O diagrama de activitate se concentreaza asupra succesiunii in executie a actiunilor si asupra conditiilor (trigger sau guard) care declanseaza aceste actiuni. o diagrama de activitate poate modela un use-case anume. Evenimentele pot fi atasate doar de tranzitiile care leaga punctul de start de primul action-state. de fapt conform specificatiilor UML o diagrama de activitate poate fi considerata o varianta a unei diagrme de stari. O actiune este facuta pentru a produce un rezultat. Tranzitiile dintre stari au aceeasi sintaxa ca la statechart. Implementarea unei operatii poate poate fi descrisa ca un set de actiuni avand legatura. adica o conditie care la un moment dat poate lua valoarea Adevarat sau Fals. Acestea vor avea atasate niste guard-uri. In proiectele in care sunt prezente use-cases. Exemplu: In diagramele de activitate. si folosite pentru: • reprezentarea actiunilor executate odata cu o operatie (instanta implementarii unei operatii) • reprezentarea activitatii interne a unui obiect • a arata cum un set de actiuni pot fi execuate si cum vor afecta obiectele din jur • a arata cum functioneaza anumite sisteme. trecerea de la o stare la alta (stare = action-state) se face atunci cand actiunea starii respective este terminata ( => nu este necesara specificarea unui eveniment ca in diagramele statechart ). De asemenea.

Pentru a arata explicit unde sunt facute actiunile (in ce obiect). tranzitia se va face numai atunci cand conditia va lua valoarea de adevar True. iar activitatile corespunzatoare unor astfel de swimlanes vor fi plasate in interiorul dreptunghiurilor. iar in cazul in care aceste tranzitii paralele se vor uni (printr-un Join) este foarte important ca ele sa-si termine actiunea inainte de unire. se folosesc asanumitele swimlanes. Fiecarui swimlane ii este dat un nume.Cand tranzitiile sunt protejate de conditii guard. care este pus in partea superioara a dreptunghiului. Folosind un Fork. Acestea se prezinta sub forma unor dreptunghiuri. o tranzitie poate fi divizata in doua sau mai multe tranzitii. \ 15 . Aceste actiuni vor fi executate concurent.

Collaboration Rol e role name Class role name role name role name Diagramele de colaborare sunt o alta modalitate de reprezentare a interactiunilor si a relatiilor dintre obiecte. Este foarte utila modelarea interactiunilor pentru un sistem in timp real. Spre deosebire de diagramele de tip sequence. Mesajul acesta va fi de cele mai multe ori un apel de procedura (operatie). o diagrama de colaborare poate fi folosita sa ilustreze executia unei operatii. precum si o transmitere simultana a mai multor mesaje. Un interes special il au in diagramele collaboration mesajele schimbate de obiecte precum si scopul pentru care sunt schimbate aceste mesaje. Legaturile arata foarte mult cu asocierile insa le lipseste multiplicitatea. ca in figura de mai jos. O colaborare defineste rolurile care vor fi jucate atunci cand se executa subrutinele unui sistem. Aceste roluri vor fi jucate de instante ale claselor aflate in directa interactiune.Collaboration diagram Collaboration diagrams descriu atat natura statica cat si natura dinamica a unui sistem. adica felul in care respectivele obiecte coopereaza pentru a defini functionalitatea unui sistem sau subsistem. O diagrama de colaborare descrie un set de obiecte impreuna cu relatiile dintre ele precum si interactiunile dintre acestea. O diagrama de colaborare incepe cu un mesaj care initiaza intreaga interactiune sau colaborare. a unui use-cases sau pur si simplu sa ilustreze un scenariu de interactiune intr-un sistem. insa numele obiectului este subliniat (numele simbolului obiect). Diagramele de colaborare arata obiecte si legaturile dintre acestea. ele nu se concentreaza pe succesiunea in timp a interactiunilor ci mai degraba pe conexiunile structurale dintre obiectele care colaboreaza si pe rolurile pe care acestea le joaca in cadrul unei colaborari. precum si felul in care mesajele sunt trimise intre obiectele conectate (prin legaturi). La fel ca si o diagrama de secventa. 16 . Obiectele sunt desenate la fel ca si clasele (in forma restransa). Mesajele (stimulii) sunt folositi pentru a descrie interactiunea dintre obiecte si lor li se pot atasa cate o eticheta-mesaj care defineste printre alte lucruri si un numar de secventa pentru mesajul respectiv. pentru ca astfel se poate ilustra atat structura statica cat si cea dinamica a obiectelor care se afla in interactiune. O singura diagrama de colaborare poate reprezenta mai mult de un fir de executie.

Exista mai multe tipuri de mesaje si anume: . dar vor continua cu un sufix diferit in ordinea in care mesajele vor fi transmise.Un actor trimite un mesaj pentru printare catre un computer. Adnotari cu privire la timp pot fi adaugate diagramelor de colaborare. Obiectele. Numele claselor sunt precedate de “:”. inainte ca obiectul care a initiat primul mesaj sa-si continue executia. Un mesaj simplu si unul sincron pot fi combinate pentru a arata ca la transmiterea mesajului. de obiecte sau cu ambele. iar mesajele de pe acelasi nivel (trimise in timpul aceluiasi apel) au acelasi prefix. Rolul jucat de un obiect intr-o colaborare va fi aratat la capetele link-urilor. acest tip de mesaj este folosit este folosit cand nu se cunosc detalii despre comunicare sau cand aceste detalii nu sunt considerate relevante in diagrama la care se lucreaza. .global: specifica faptul ca instanta respectiva este vazuta in intregul sistem si poate fi apelata folosind un nume cunoscut oriunde in sistem . Mesajele (stimulii) vor fi pozitionati de-a lungul acestora. cel care porneste o secventa intreaga de mesaje va fi numerotat cu 1 .sincrone: similare cu un apel al unei operatii.mesajul1.parameter: specifica faptul ca instanta respectiva este vazuta deoarece este un parametru a unei operatii . care la randul lui va trimite un mesaj de imprimare catre imprimanta (daca aceasta este libera). vor fi etichetate cu nume de clase.1.association: specifica faptul ca instanta respectiva este vazuta doar de catre obiectele aflate in asociere . iar cele care sunt distruse in timpul colaborarii vor avea constrangerea {destroyed}.b vor fi folosite pentru doua mesaje care vor fi trimise in paralel.1 este primul mesaj care decurge din rezolvarea primului mesaj . Aceste adnotari vor fi de fapr notite sau constrangeri atasate diferitelor elemente din diagrama. . Obiectele care sunt si create si distruse in cadrul aceleiasi colaborari vor avea constrangerea {transient}care este echivalenta cu {new}{destroyed}. Computerul trimite un mesaj de printare serverului. mesajele simple mai sunt folosite pentru a arata faptul ca controlul este dat inapoi de la obiectul care a primit un mesaj sincron la cel care a initiat acel mesaj. operatia care primeste mesaul isi termina toate operatiile (inclusiv transmiteea de alte mesaje). Primul mesaj va fi numerotat cu 1. . fara sa astepte rezultatul operatiilor care se vor executa odata cu transmiterea mesajului.self: specifica faptul ca instanta respectiva este vazuta doar de catre ea insasi Obiectelor create in timpul unei colaborari vor avea constrangerea {new}. De exemplu 2.a si 2. aceasta reintoarcere catre primul obiect poate fi reprezentata ca un mesaj sau poate fi considerata implicita la terminarea operatiei care se ocupa de mesajul transmis. acesta continuandu-si executia dupa transmiterea mesajului. insa nu asa clar ca intr-o diagrama de tip sequence.1. 17 .simple: arata cum controlul este pasat de la un obiect la altul fara a se da vre-un detaliu despre comunicare. cele care joaca rolurile din digrama de colaborare. Unui astfel de rol i se pot atasa diferite stereotipuri cum ar fi: . Un Link este o conexiune dintre doua obiecte care colaboreaza.mesajele trimise in paralel.asincrone: sunt folosite acolo unde nu exista o reintoarcere explicita in cadrul obiectului care initiaza mesajul. iar fiecare mesaj din diagrama are un numar care va indica succesiunea acestora.mesajul 1.local: specifica faptul ca instanta respectiva este vazuta deoarece este o variabila locala intr-o operatie.primul mesaj. adica cele concurente pot fi descrise folosind litere in cadrul expresiei numerice care exprima succesiunea mesajelor. returnarea controlului are loc aproape instantaneu.2 este urmatorul . Mesajele sunt numerotate astfel: . acest tip de mesaj este folosit in sistemele in timp real unde obiectele se au o executie concurenta.

Un obiect activ se executa deodata cu thread-ul sau de control. un telefon si un alarma sonora) si un semnal de tot asincron catre System Handler. va trimite un stimul pentru declansarea alarmei interne.Diagrama de colaborare din figura de mai sus arata interactiunile care au loc cand un senzor al unei alarme detecteaza ceva. O diagrama de colaborare furnizeaza o poza buna a ambelor structuri a obiectelor implicate si interdependenta lor. 18 . Elevator control creeaza o noua sarcina pt lift pe care o introduce in coada liftului. iar apoi va scrie evenimentul intr-un fisier log. Un actor de la un anumit etaj apasa un buton. System Handler folosind Superviser. In continuare Cell Handler trimite in paralel semnale (mesaje) asincrone paralele catre toate alarmele (in acest caz. Obiectul elevator este activ. ruleaza concurent si isi extrage noile sarcini din coada sa. Acesta trimite un semnal de alarma asincron catre Cell Handler.

Folosit pentru a distruge un obiect la un anumit dat in cadrul secventei de interactiuni. Daca o instanta a unei clase trimite un mesaj (stimul) unei alte instante. Frecvent acest tip de diagrame vor fi situate sub Use-Cases sau sub diferite componente pentru a ilustra un scenariu (nu un algoritm). • Destroy stimuli . 19 . O diagrama de secventa are doua dimensiuni: . o diagrama de secventa va consta dintr-un set de obiecte. Actiunea executata este de cele mai multe ori o operatie implementata in cadrul clasei obiectului care primeste mesajul. O astfel de diagrama va arata ce obiect initiaza activitatea intr-un sistem. Linia vietii acelui obiect care va fi distrus se va termina printr-o cruce in momentul trimiterii stimulului. sau niste succesiuni de pasi care sunt parcursi la aparitia unui eveniment. Asadar o diagrama de secventa va reprezenta un scenariu Use Case (sau o parte a unui scenariu Use Case) sau un curs al evenimentelor. Elementele uneidiagrame de secventa: • Objects – Elementele responsabile cu transmiterea si receptionarea mesajelor • Call stimuli – Reprezinta un mesaj sincron (care este vazut ca un apel de functie) • Send stimuli – Reprezinta un mesaj asincron (care este vazut ca un semnal)Cel care transmite mesajul nu asteapta un raspuns de la cel care primeste mesajul.Sequence Diagram O diagrama de secventa este o diagrama ce descrie structura dinamica a unui sistem aratand interactiunile dintre instantele unor clase (obiecte) in momentul rularii programului (functionarii sistemului). Ca notatie UML.dimensiunea orizontala: arata obiectele catre care sunt trimise mesajele (Obiectele implicate sunt listate de la stanga la dreapta dupa momentul in care sunt implicate in secventa de mesaje) Obiectele care vor participa la interactiuni vor avea urmatoarea sintaxa: InstantaClasa : NumeClasa (ex. • Return stimuli – Reprezinta ceea ce se returneaza in urma unui call stimulus. Numele mesajului (stimulului) precum si a actiunii care se va executa vor fi plasate deasupra acestei sageti. ce procese si schimbari vor avea loc intern in cadrul sistemului si ce date de iesire vor fi generate in urma interactiunilor dintre obiecte. • Create stimuli – Folosit pentru a crea un nou obiect la un anumit dat in cadrul secventei de interactiuni. Aceasta linie a vietii reprezinta timpul cat obiectul respectiv continua sa existe si ajuta la reprezentarea mesajelor (atat cele primite cat si cele transmise) si activarii obiectelor. myReportGenerator : ReportGenerator). Daca aceasta operatie returneaza o valoare care este importanta in desfasurarea executiei programului. orientata spre obiectul apelant (numita return stimulus in Poseidon). se va desena o sageata (deschisa) orientata spre instanta care va primi mesajul. care este determinata prin citirea diagramei de sus in jos. Mesajele (stimulii). se poate desena o sageata punctata. oferind o harta a modului de transmitere a mesajelor intre obiecte in timp (=> se modeleaza operatiile care vor trebui incluse in clasele sistemului precum si evenimentele suportate de clase). fiecare avand o linie verticala punctata care reprezinta viata obiectului respectiv (linia vietii).dimensiunea verticala: arata succesiunea mesajelor/apelurilor ordonate in functie de momentul in care apar (functie de timp) . sunt desenate ca fiind sageti trasate de la un obiect la altul. concentrandu-se pe succesiunea in timp a interactiunilor din timpul executiei.

obiecte. Ele sunt blocurile care alcatuiesc sistemul distribuit pe diferite alte elemente hardware (aceste elemente hardware pot fi si computere diferite). Scopul ei este de a arata dependentele pe care software-ul dezvoltat le are cu alte componente software din cadrul sistemului (Ex: biblioteci de functii).Component and Deployment Diagrams Majoritatea uneltelor Case existente permit crearea unei astfel de diagrame sub denumirea de deployment diagram. Fiecare componenta va oferi servicii altor componente (numite clienti). nici Poseidon nefacand exceptie de la aceasta. De fapt ele sunt artefacte de nivel inalt cum ar fi java beans. Exemple de componente: • ActiveX Control: set de tehnoloogii Microsoft care ofera continut interactiv pt World Wide Web (efecte multimedia. Componentele mai pot fi vazute si ca implementarea in arhitectura fizica a unui sistem a conceptelor si functionalitatilor definite in arhitectura logica (clase.sunt folosite pentru a ilustra relatiile de comunicare dintre noduri. • Dependencies – acestea exista intre diferite componente si pot fi specificate utilizand stereotipi (predefinite sau nu). de multe ori compuse din alte elemente mai simple cum ar fi clase si functii din biblioteci. Dupa un timp. Diagramele de componenta sunt foarte folositoare in cazul in care se lucreaza la un proiect cu un numar relativ mare de echipe de dezvoltare. ilustrand numai principalele componente la un nivel de detaliere foarte mic. ocx’s-uri si alte produse software. • Links – sunt folosite pentru conectarea obiectelor sau instantelor de noduri. In Poseidon se pot edita chiar si Object Diagrams in cadrul sectiunii diagramei Deployment deoarece s-au introdus si notatiile pentru Object in toolbar-ul aferent. O diagrama de componenta poate reprezenta sistemul la un nivel superior (high-level). Componentele sunt de fapt fisierele existente in mediul de dezvoltare folosit pentru constructia unui system.componentele si nodurile pot include obiecte. clusterele de clase cu interactiune puternica vor forma un fel de unit si vor iesi in relief in cadrul arhitecturii. Aceste clustere vor putea fi reprezentate in limbajul UML sub forma unor componente. • Associations . O astfel de diagrama ofera o vedere din punct de vedere fizic asupra sistemului. Ele ajuta la modelarea si apoi identificarea componentelor software si a interfetelor acestora. diferite relatii si colaborari). Classes. dll-uri. aceste servicii numite contracte facandu-se de obicei prin intermediul interfetelor. obiecte interactive) • Dll (dynamic link library) • JavaBean (suport pt servere de aplicatii) • Pagini Web 20 . Principalele elemente ale unei Component Diagram: • Nodes and Instances of Nodes – nodurile reprezinta elementele hardware ale sistemului distribuit (acestea sunt folosite numai in cazul diagramelor de tip deployment) • Components and Instances of Components – componentele tin locul elementelor software care sunt repartizate in hardware-ul sistemului. Interfaces . La fel ca dependentele si asocierile pot fi specificate folosind stereotipi. clase sau interfete. sau la un nivel inferior (low-level) unde vor fi ilustrate componentele pana la nivelul package-urilor. • Objects. O data ce interfetele au fost definite si acceptate de echipe este mult mai usor de organizat efortul de dezvoltare al subechipelor. ArgoUML.

o astfel de componenta are un inteles la momentul compilarii (compile time).<<thread>>: fir de executie • executable component (Run-Time Component): un fisier executabil (exe) care este rezultatul procesului de linking al tuturor componentelor binare (statrice la link-time si dinamice la runtime).<<page>>: o reprezentare a unei pagini web .• O componenta software poate fi: source component (Compile-Time Components): un fisier continand cod sursa in care sunt implementate una sau mai multe clase. sau cateodata direct din Compile-Time Components (ex.<<file>>: fisier continand cod sursa .<<process>>: simplu proces . Java). o astfel de componenta reprezinta unitatea executabila care va fi rulata de catre processor (computer) Pentru Run-Time Components se pot folosi urmatoarele stereotipuri: .<<document>>: reprezentate a unui fisier continand documentatie nu cod • binary component (Link-Time Component): cod obiect care este rezultatul compilarii a unuia sau mai multor componente sursa.<<table>>: o reprezentare a unui tabel dintr-o baza de date folosit drept componenta la run-time 21 . celelate tipuri de componente fiind generate de componente de acest tip Pentru Compile-Time Components se pot folosi urmatoarele stereotipuri: .<<application>>: reprezinta un fisier executabil . un fisier static sau dinamic de functii (library files) care are un inteles la link-time sau in cazul unei librarii dinamice la run-time (o astfel de biblioteca este incarcata de o componenta executabila doar in momentul rularii) Pentru Link-Time Components se pot folosi urmatoarele stereotipuri: . o astfel de componenta poate fi un fisier cu cod obiect (obj).

O component diagram arata felul cum sunt organizate componentele software (source. se poate ajunge la o structura arhitecturala reutilizabila care va putea fi folosita cu succes in cadrul altor si altor sisteme. O sageata punctata intre doua componente inseamna ca o componenta are nevoie de o alta pentru a fi definite complet. felul in care comunica etc. Principiile designului de componente: • nu trebuie sa existe cicluri de forma A  B  C  A unde sageata reprezinta o relatie de dependenta • daca o clasa localizata intr-o anumita componenta este schimbata atunci acest lucru nu trebuie sa afecteze clase din afara componentei respective • daca o clasa dintr-o componenta trebuie sa fie reutilizata va trebui sa fie reutilizate toate clasele incluse in acea componenta (niciodata nu se va reutiliza numai o parte a unui element software) • abstractiile nu trebuie sa depinda de detalii ci detaliile vor trebui sa depinda de abstractii • elementele software vor trebui sa fie deschise pentru extindere dar inchise pentru modificare • daca A depinde de B atunci B ar trebui sa fie mai stabila (mai putin probabil de a suferi modificari) • componenta trebuie sa fie suficient de abstracta pentru ca sa poata fi extinsa fara a-I fi afectata stabilitatea. Daca componentele intre care exista o dependenta sunt executabile atunci citind o astfel de diagrama vom putea identifica de ce librarii dinamice are nevoie un program pentru a putea rula. Componentele sunt niste tipuri. Aceste interfete pot fi definite la nivel cod (ex: interfete Java) sau binary. 22 . o schimbare in B necesita o recompilare si a lui A. In timp. folosite la run-time (ex. Atunci am avea urmatoarea diagrama de componenta: In UML o componenta este ilustrata sub forma unui dreptunghi uneori avand o elipsa plus inca doua mici dreptunghiuri in stanga. binary. simpla ar include doar butoanele obisnuite . OLE). executable). construind astfel de componente in cadrul unei arhitecturi. insa numai componentele executabile pot avea instante (atunci cand programul pe care-l reprezinta este executat de compilator ). relatiile dintre si dependentele existente intre acestea.Sa presupunem ca dorim sa construim un software pentru muzica de pe CD-uri (un player) a carui interfata. O componenta poate sa implementeze una sau mai multe interfete care sa poata fi vazute de alte componente (=>publica comportamentul componentei respective). O astfel de dependenta intre o source component A si o source component B inseamna ca. O astfel de diagrama este folosita de obicei pentru prezentari de marketing sau rezumate a arhitecturii unui sistem.

2 API. avand insa si cateva adaugari cum ar fi conceptul de nod care reprezinta de fapt o masina (reala sau virtuala). Servlet 2. O deployment diagram sa o network diagrams cum i se mai spune descrie felul cum componentele sunt repartizate pe diferitele computere existente in cadrul unui sistem.2 API. Notatiile dintr-o deployment diagram includ elementele notationale folosite intr-o component diagram. va fi o caracteristica a unei componente ce specifica un punct de interactiune a componentei cu mediul extern.Legatura unei componente cu o anumita interfata poate fi reprezentata in doua moduri. O component diagram va arata o componenta numai sub forma unui tip. Acest simbol poate fi considerat un stereotip vizual pentru o dependenta. asadar s-ar putea spune ca o deployment diagram modeleaza sistemul la run-time. Componenta ofera de obicei o interfata si in acest caz se va folosi notatia tip lollypop. and JDBC API. dupa caz. Scopul unei astfel de diagrame este de a ilustra unde vor rula (dpdv fizic) diferitele componente si cum vor comunica una cu alta. dupa felul acestei legaturi. Un port (notatia UML = patrat mic). and JDBC API inseamna ca Reporting Tool este dependent de aceste trei componente. Existenta sagetilor care pleaca de la componenta Reporting Tool catre componentele Billboard Service. Figura de mai jos ilustraza patru componente: Reporting Tool. Servlet 2. Cel mai simplu exemplu de deployment diagram ar fi diagrama care descrie un PC: 23 . Billboard Service. (in locul lui poate fi folosita o dependenta obisnuita cu stereotipul <<require>>). deci daca avem nevoie de reprezentarea unei instante a unei componente vom trebui sa folosim o deployment diagram. Nu este nevoie sa fie folosite toate interfetele unei componente. Aceste porturi care pot avea si un nume vor putea suporta o comunicatie unidirectionala sau bidirectionala. Incepand cu UML2 a fost introdusa simbolul de socket pentru a indica faptul ca este nevoie de implementarea unei interfete.

Reporting Tool se conecteaza la baza sa de date folosind limbajul Java si interfata IBM JDBC API. 24 . Componenta Report Tool comunica folosind SOAP over HTTPS cu Billboard Service.Diagrama de tip deployment din figura de mai sus arata faptul ca userul acceseaza Reporting Tool folosind un browser care ruleaza pe o masina locala si se conecteaza la Reporting Tool prin intranetul companiei folosind protocolul HTTP. Aceasta ruleaza (dpdv fizic) pe serverul de aplicatii. Diagrama arata componenta Reporting Tool desenata inauntul componentei IBM WebSphere. care apoi comunica cu baza de date Reporting aflata pe serverul MySQL Server folosind interogari SQL. care la randul ei este desenata inauntrul nodului care reprezinta serverul de aplicatii.

techit.techit.php 10) http://www.pdf 6) http://funinf.ro/~vcioban/Informatica/Anul3/SIPP/Esit/curs/Modelare %20OO%20UML%20GRAPPLE.au/uml-tutorial.ro/tutorial_uml_2.unibuc.ubbcluj.php 25 .htm http://www.ro/tutorial_uml_1.ici.uaic.org/ http://www.ro/~gheorghe/curs/metDezvSoft/lec/l05four.uml.ro/~giurca/courses/CB3105/resources/Introducere%20in %20UML.ro/RRIA/ria2004_3/art08.techit.ro/tutorial_uml_3.visual-paradigm.php 11) http://www.ucv.pdf 7) http://cs.Bibliografie: 1) 2) 3) 4) 5) http://www.com.html http://www.doc 8) http://thor.com/ http://inf.info.cs.sparxsystems.ro/~adrianaa/uml/ 9) http://www.

Sign up to vote on this title
UsefulNot useful