analiza obiectuala a sistemelor in format ice ( aplicatie uml )

8/6/2019 Analiza Obiectuala a Sistemelor In Format Ice ( Aplicatie UML )

1/25

Universitatea de Vest TimisoaraFacultatea de Economie si de Administrarea a AfacerilorContabilitate si Sisteme Integrate in Corporatii

Analiza obiectuala a sistemelorinformationale

( aplicatie UML )

2011

1


2/25

Cuprins :

1. The Unified Modeling Language (UML) ..pg.2

2. Use-case Diagram ..pg.5

3. Class Diagram ....pg. 84. Action diagram .. pg. 125. Collaboration diagram ...pg. 146. Sequence Diagram .....pg. 17

7. Component and Deployment Diagrams ...pg. 188. 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


3/25

module cat mai mici a produsului pentru usurinta implementarii), implementarea (scriereaefectiva a codului) si testarea.

In cadrul lucrului la un proiect software sunt implicate mai multe persone, fiecare areatribuii complementare celorlali. Se pot distinge mai multe specialitati:

utilizatori - exploatatorul softului;efi de proiect - totdeauna trebuie s existe cineva cu aceast funcie;

analiti de sistem - execut modelul informatic al aplicaiei;proiectani de sistem - execut arhitectura programului aplicaiei;programatori - execut modulele;ingineri de test - verific ceea ce s-a creat.Activitatea n echip este puternic interactiv, comunicarea dintre membrii personalului

cu specialitati diferite facandu-se de obicei prin intermediul formularelor si rapoartelor, care deobicei devin greu de urmarit din pricina formatarii sau a lipsei de organizare a acestora sau chiar aomiterii anumitor detalii despre o anumita componenta (modul).

In cadrul fazei de proiectare se construieste de obicei un modul al proiectului la care selucreaza. Modelarea este o parte esentiala a unui proiect software, el jucnd un rol analog cuproiectul architectural al unei cladiri de mari dimensiuni. Folosind un model ce-i responsabilipentru 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, robustete, extendabilitate etc.

In cadrul operatiunii de modelare se pleaca de la premisa ca sistemele software suntcomplexe, de aceea avem nevoie de o multitudine de viziuni simple ale acestora asfel incat infinal sa stapanim complexitatea.

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.UML este produsul a multi ani de munca a mai multor companii cu renume in lumea IT

dintre care amintim Sun Micro Systems , Oracle Corporation, Hewlett-Packard Company,IBMCorporation, SAP sub patronajul si sponsorizarea concernului OMG (Object Management Group

fondat in 1989).UML este un limbaj grafic creat pentru vizualizarea, specificarea, construirea si

documentarea sistemelor software incluznd atat structura ct i designul acestora ce poate fiaplicat si in alte domenii cum ar fi afaceri sau alte sisteme non-software. Chiar daca UML nupoate garanta succesul unui proiect, 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 sicomplexe.

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 complexeindiferent de domeniu (industrial, software, marketing, constructii etc.).

3


4/25

UML ofera un model standard de a scrie documentatie de sistem, functii de sistemprecum si alte lucruri concrete cum ar fi declaratii intr-un anumit limbaj de programare, schemeale bazelor de date si componente software reutilizabile.

Unified Modelling Language (UML) este un limbaj de modelare si nu o metoda sau un

proces. UML are notatii specifice si reguli gramaticale bine precizate pentru construireamodelelor software.

Exista o bogata colectie de elemente notationale grafice suportate de UML. Exista o seriede elemente care descriu clase, componente, noduri, activititati, work flow, obiecte, stari darexista si elemente grafice care ajuta la modelarea relatiilor intre elementele amintite.

UML suporta notatii pentru extinderea puterii limbajului de modelare (referirea se face

aici la elementele de tip stereotype si constraints), asigurand avantaje semnificante inginerieisoftware ajutand la construirea de modele rigurase, usor de urmarit si intretinut, care sa suporteintregul ciclu de dezvoltare software.

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. Prin abstractizareatentia se concentreaza asupra detaliilor semnificante ignorandu-le pe celelalte. Aceasta estecauza 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 realitateEste necesara constructia unui model pentru sistemele complexe deoarece mintea umana

nu poate acoperi toate detaliile unui astfel de sistem. Cu cat complexitatea unui sistem creste cuatat creste si importanta folosirii unei bune tehnici de modelare si implicit a unui limbaj rigurosde modelare cum este UML.

UML, 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 careruleaza pe orice combinatie de hardware, sistem de operare sau tip de retea. Flexibilitatea luipermite modelarea aplicatiilor distribuite ce folosesc orice tip de middleware de pe piata, iardatorita 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++,Java, C#). Trebuie precizat insa ca limbajul UML se poate folosi si pentru a modela aplicatii non-OOP in limbaje precum Cobol, Fortran, sau Visual Basic .

Designul software nu este un simplu proces automat de transformare a unei specificatii in

alta. El implica si luarea unor decizii complexe care se vor repercuta asupra produsului final.Uneltele pentru design, cele care ajuta designerii in luarea deciziilor sunt un mijloc important de a

creste productivitatea si calitatea designurilor software rezultate.Astfel au aparut uneletele CASE (Computer Aided Software Engineering), care se gasesc

in numar foarte mare si au grade diferite de utilizabilitate. Din ele se pot distinge: Rational Rose,ArgoUml, Poseidon (Gentleware).

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. Printreaceste standarde folosite se afla: in primul rand UML-ul, apoi XML MetadataInterchange (XMI), Scalable Vector Graphics (SVG), Object Constraint Language(OCL).

4


5/25

implementeaza toate specificatiile limbajului UML 1.3., fiind singura unealtacare 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 intotalitatea sa. De aceea ei trebuie sa construiasca un design partial, sa-l evalueze, eventual

sa-l modifice pana cand vor fi pregatiti sa extinda acel design partial ( tirania paginiialbe este un efect similar)

design oportunistic: descompunerea ierarhica este o strategie uzuala in designulsistemelor complexe . Totusi in practica s-a observat ca designerii lucreaza la module

alese oarecum oportunistic, functie de efortul mental pe care trebuie sa-l depuna la unmoment dat

generare si explorare: in prima faza sunt generate noi idei care mai apoi, in faza adoua 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, package-urile, proprietatile lor si diferitele relatii carepot aparea intre acestea.

Object diagrams: descriu un anumit scenariu, in loc de clase, ca la class diagrams voraparea obiecte, instante ale acestor clase.

Use-case diagrams: descriu use cases, actorii implicati (cei care interactioneaza cusistemul), pus diferitele relatii existente.

5


6/25

Sequence diagrams and Collaboration diagrams: descriu secventa de mesajeschimbate de obiecte la run-time.

Statechart diagrams:prezinta starile pe care le pot avea obiectele in cadrul unui sistem.

Activity diagrams: prezinta algoritmi sau data-flow.

Component diagrams: descriu componentele implementate (Ex: source & object files)

Deployment diagrams: descriu felul cum componentele sunt repartizate pe diferitelecomputere.

Use-case Diagram

Un caz de uz (use case) este o tehnica de modelare folosita pentru a descrie functionalitateaunui sistem, deci ce ar trebui sa faca un nou sistem sau ce face deja un anumit sistem. S-ar puteaspune chiar ca o diagrama use-case descrie ceea ce face un sistem din punctul de vedere al unui

observator extern, aceasta descriere fiind independenta de implementare. Adesea, o astfel dediagrama este folosita in etapele preliminarii a procesului de design pentru a colecta cererileclientului cu privire la proiect. Asadar, constructia unui model use-case, reprezentat printr-odiagrama 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.Un model use-case va descrie si va trebui sa surprinda felul in care un actor va folosi un

anumit sistem.Pentru a crea un model use-case trebuie parcursi mai multi pasi si anume: definirea sistemului,

identificarea actorilor si a use-case-urilor, descrierea use-case-urilor, definirea relatiilor dintreuse-cases iar in final validarea modelului. Descrierea use-case-urilor se face fie printr-un text

scris, fie prin conceperea unei diagrame de activitate.Cel mai important scop al unei diagrame use-case este de a ajuta dezvoltatorii de sisteme softwaresa vizualizeze cerintele functionale ale unui astfel de sistem sau unitati de sistem.Dintre use-cases, actori si dependente, actorii sunt pentru programatori cele mai neimportante

elemente ale unei diagrame use-case. Relatiile sunt de fapt cele mai importante deoarece acesteale sugereaza care dintre use-case-uri sa fie implementat prima data. De regula se incepe cu use-case-ul cu cele mai multe dependente deoarece alte use-case-uri depind de acesta.Din punct de vedere grafic o diagrama use-case este un graf avand drept noduri actori si use-

cases, iar drept muchii diferite relatii intre aceste elemente. Actor este o entitate externa (persoana sau echipament) care are un interes in a

interactiona cu sistemul, deci va face un schimb de informatii cu sistemul (schimbamesaje). Un actor reprezinta un rol nu un utilizator individual al sistemului. Asadar unactor reprezinta o clasa nu o instanta avand stereotipul si deci poate avea atatatribute cat si operatii (behaviours), precum si o documentatie in care sunt descrise

acestea.

6


7/25

Sterotipii extind vocabularul UML sunt folositi la etichetarea artefactele UML pentru aindica ca acestea apartin unei anumite categorii, sau pur si simplu pentru a reda mai multeinformatii despre artefactul UML.

Un actor are un nume, iar numele acestuia trebuie sa reflecte rolul actorului. Actorii pot fi

categorisiti in actori primari si secundari sau in actori activi (cel care initiaza use-case-ul) saupasivi (doar participa intr-un use-case). Intr-o diagrama actorii pasivi se pot deosebi de cei activi

dupa sensul asocierilor.Identificarea actorilor din cadrul unui sistem se face raspunzand la urmatoarele intrebari:

1. Cine va folosi principalele functionalitati ale unui sistem? (actori primari)2. Cine are nevoie de sprijin in realizarea indatoririlor zilnice? (useri)

3. Cine va trebui sa intretina, administreze si sa mentina in stare de functionalitatesistemul?(actori secundari)

4. Cu ce alte sisteme va trebui sistemul nostru sa interactioneze?(sistem = altcomputer sau alte aplcatii de pe computerul pe care se dezvolta sistemul)

5. 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; dacase depaseste numarrul, proiectul se va sparge in mai multe bucati). De fapt un use-case

reprezinta o functionalitate completa a unui sistem asa cum este vazuta de catre un actor.

Identificarea use-case-urilor ce trebuiesc modelate intr-un sistem se face raspunzand laurmatoarele intrebari:

1. Ce vrea un actor de la sistem? Ce anume vrea el sa faca?2. Are nevoie un actor sa citeasca, creeze, distruga, modifice sau depoziteze vre-un

tip de informatie in cadrul sistemului?3. Actorul trebuie sa fie anuntat de evenimentele din sistem, 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. este initiat intotdeauna de catre un actor2. intoarce o valoare catre un actor3. este complet (valoarea finala este produsa)

Un use-case trebuie sa aiba un nume care de regula este o fraza care descrie cat mai binefunctinalitatea use-case-ului. La fel ca si actorii, un use-case este o clasa si nu o instanta, aceastaclasa descriind functionalitatea ca un intreg, incluzand posibile alternative, erori si exceptii care

pot sa apara in timpul executiei unui use-case. O instanta a unui use-case poarta numele descenariu, reprezentand de fapt un caz de folosinta a sistemului.

Extension Points - Este o referinta catre o locatie dintr-un use-case unde se pot inserasecvente din alte use-cases (fiecare extension point are un nume unic in cadrul use-case-

ului).

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 (maispecific) care este perfect compatibil cu elementul parinte adaugand insa si elemente aditionale.

7


8/25

Generalizarea este folosita pentru actori, use-cases, clase, package-uri etc, deci pentru tipuri,niciodata pentru instante. Relatiile de generalizare sunt numite cateodata relatii este un/o (Omasina este vehicul => generalizarea masinii este un vehicul) si sunt folosite pt a descriecomportamentul comun al unui anumit numar de elemente. Elementul specializat (fiu) mosteneste

comportamentul elementului general (superclasa sau parintele) extinzand intr-un anumit fel acestcomportament. O astfel de relatie poate avea un nume si un stereotip.

Exemplu de generalizare: un proiect este un proiect intern sau extern.

Associeri: Apar intre diferite elemente (Ex: actori si use-cases) si pot fi navigabile inambele directii, intr-o singura directie sau nenavigabile. O asociere intre doua elemente arinsemna (s-ar traduce) ca elementele aflate intr-o relatie de asociere stiu una de alta, suntconectate, sau pentru fiecare X exista un Y (sau mai multi de Y, asta depinzand de

multiplicitate). Reprezentarea grafica a unei asociatii este o linie simpla care poate avea si unstereotip. In cadrul diagramei use case-urile sunt conectate de actori cu ajutorul asociatiilor, carearata cine cu cine comunica precum si care este actorul care initializeaza un use-case. Lipsa uneisageti indica faptul ca comunicarea se face 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 respectivaasociere.

O asociere are doua capete. Multiplicitatea unui capat al asociatiei reprezinta numarulposibil de instante asociate cu o singura instanta a celuilalt capat.

Numarul respectiv poate fi un singur numar sau o serie de numere. De exemplu poate fi unsingur client pentru o comanda, dar un client poate face oricate comenzi.

Iata principalele multiplicitati folosite:

0..1 zero sau o instanta

0..* nici o limitare la nr. de instante

1 exact o instanta

1..* cel putin o instanta

Aggregation- O asociatie in care un element este parte a unui intreg reprezentat de

celalalt element. Exista mai multe tipuri de agregari cum ar fi:1. agregari fixe (au un nr. prestabilit de componente)2. agregari variabile (numar variabil dar finit de componente) Ex: liste, vectori3. agregari recursive Ex: arborii binari contin arbori binari

Composition Este o puternica forma de agregare in care elementul parte este distrusautomat in momentul distrugerii elementului intreg. In cadrul unei agregari elementul parte maiexista si dupa ce elementul intreg este distrus. Ca si la agregare pot fi compozitii fixe, variabilesi recursive.

Dependente Pot exista o serie de dependente semantice intre diferite element alemodelului (si intre use-cases) si are rolul de a sugera ca un element foloseste un alt element, deci

depinde de acel element. Urmand sensul dependentei, o schimbare in specificatia unui element arputea afecta si pe elementul aflat in relatie de dependenta cu primul. Acestea au de obicei un

stereotip pentru o mai buna definire a rolului dependentelor. Exista doua tipuri speciale dedependente: si .

Extend relationship O relatie unidirectionala intre doua use-cases. O relatie de tipextend intre B si A (B, A = use-cases) inseamna ca caracteristicile lui B pot fi incluse in

A.

8


9/25

Include relationship - O relatie unidirectionala intre doua use-cases. O astfel derelatie intre use-case-urile A si B inseamna ca, inseamna ca caracteristicile lui B vor fiintotdeauna incluse in 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 aacelor actori din care sa derive acestia folosind relatia de generalizare.

Daca exista similaritati intre o serie de use-cases care cum ar fi un flux comun deactivitati (eventual folosit in mod repetat) atunci s-ar putea crea un nou use-case care safie folosita de catre primele folosind relatia de incluziune ().

Daca exista un caz apecial al unui use-case atunci se va folosi o relatie de tip.

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 seva crea un nou use-case pt respective functionalitate.

Class Diagram

Class diagrams sunt probabil cele mai importante diagrame UML. In modelarea orientatape obiecte , clasele, obiectele si relatiile dintre ele sunt principalele elemente pentru modelare.Cand se foloseste programarea orientata pe obiecte pentru realizarea sistemelor software, claselesi relatiile devin chiar codul insusi.

O class diagram arata cum diferitele entitati (persoane, lucruri si date) sunt relationateintre ele, scopul ei principal fiind acela de a descrie structura statica a sistemului care este

modelat. Spunem ca diagramele claselor sunt statice deoarece nu descriu ceea ce se intampla inmomentul in care clasele relationate interactioneaza.

Clasele sunt cele mai importante concepte in programarea orientata pe obiecte si s-arputea spune si in limbajul UML. Principalele proprietati ale unei clase sunt: numele, stereotipul si

vizibilitatea (public, protected sau private).Modeland structura statica a claselor, o class-diagram prezinta structura interna a fiecarei

clase (atribute, operatii) precum si cel mai important aspect si anume relatiile pe care fiecaredintre clase le are cu celelalte clase (asocieri, generalizari etc).

Pentru a crea o class diagram, clasele trebuie sa fie identificate si descrise.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 mnuiasca? Exista biblioteci sau componente din alte proiecte care vor fi folosite in sistem?

Actorii folositi (din use-cases) au un rol in sistem a.i. vor trebui implementati ca fiindclase?Daca se raspunde cu da la una dintre aceste intrebari atunci vom avea un posibil candidat

de a fi implementat drept clasa.

Clasele pot fi impartite in clase:

active: cele care initiaza si contoleaza fluxul activitatii

9


10/25

pasive: depoziteaza informatii si servesc celorlaltor clasesau clase

abstracte: nu pot fi instantiate obiecte de tipul acestor clase (folosite pentru mostenire: oclasa care mosteneste o clasa abstracta, avand functii abstracte, va trebui neaparat sa

implementeze aceste operatii => sa le scrie codul)

concrete: opusul a ceea ce se numeste clasa abstractaIn ambele cazuri, cand exista o mostenire, daca se rescrie codul unei operatii, 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. Notatia UML pentru o clasa este un dreptunghi imparit in trei parti: numele clasei,

atributele si operatiile. O clasa abstracta va avea numele scrise cu caractere italice. Relatiile dintreclase vor fi reprezentate de liniile conectoare. Unele dintre aceste tipuri de relatii sunt dejacunoscute ele aparand si la diagramele de tip use-case.

10


11/25

Primul compartiment al dreptunghiului clasei si anume numele clasei este de obicei unsubstantiv care trebuie sa fie derivat din domeniul problemei analizate si de asemenea trebuie safie cat mai putin ambiguu posibil.

Pentru un mai mare grad de abstractizare se poate apasa Hide all compartments, ceea

ce va duce la afisarea clasei sub forma unui mic dreptunghi simplu (nu vor mai fi afisatecompartimentele aferente atributelor si operatiilor).

Celelalte compartimente sunt cele corespunzatoare atributelor si operatiilor.Un atribut este folosit pentru a pastra informatii care descriu si identifica o instanta

specifica a clasei. Un atribut are un tip care poate fi predefinit sau primitiv (integer, real, String,byte, char ) sau poate fi o instanta a unei clase construite tot de noi. (In lista tipurilor ne vor

aparea si clasele definite de noi deci unui atribut va putea fi de un astfel de tip). Ceea ce trebuiementionat este faptul ca aceste tipuri primitive nu apartin limbajului UML, ci unui anumit limbajde programare setat in cadrul unealtei CASE folosite.

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.Acestia sunt public (accepta referirea din alte clase), private (nu accepta referirea din alte clase) siprotected (accepta referirea numai din clasele fiu => protected este folosit impreuna cu o relatiede generalizare sau specializare). Asadar declaratorii de acces sunt folositi pentru specificarea

modului de acces la informatiile incapsulate in clase.Am vazut ca atributele sunt valori care caracterizeaza obiectele clasei, cateodata valorile

atributelor fiind o cale de a descrie starea obiectului. Operatiile, cele afisate in al treileacompartiment al figurii ce reprezinta clasa sunt folosite pentru a manipula atributele sau pentru a

performa alte actiuni. Operatiile sunt de obicei numite functii sau metode, dar ele sunt interioareunei clase si deci vor putea fi aplicate numai obiectelor clasei. O operatie are un tip returnat, un

nume si zero sau mai multi parametrii. Impreuna, tipul returnat, numele si parametrii sunt numitesignatura operatiei. Signatura descrie tot ce este nevoie pentru a folosi operatia.

Pentru a performa o operatie, o operatie este aplicata unui obiect al clasei (este numit peun obiect). Operatiile intr-o clasa descriu ce poate face o clasa, ce servicii ofera, si pot fi vazute

ca fiind interfata unei clase.Este posibil ca o operatie sa aiba o valoare de tip default pentru un parametru. Aceasta

inseamna ca in cazul in care apelantul operatiei nu specifica un parametru operatia va folosivaloarea default pt acel parametru.

Cand un obiect (instanta al unei clase) este creat, atributele si linkurile ar trebui sa fieautomat initializate. Pentru acest lucru am putea avea o operatie statica care sa faca acest lucrusau am putea crea un asa-zis constructor, cel care va corespunde unui constructor dintr-un anumitlimbaj de programare (C++, Java). In UML un constructor este redat printr-o operatie avand

acelasi nume cu clasa care are stereotipul create. O operatie avand stereotipul destroy esteechivalentul unui destructor din C++ si va fi responsabila in eliberara spatiului de memorie alocatobiectelor dinamice.

Cuvantul cheie leaf pentru o clasa indica faptul ca acea clasa nu este conceputa pentru

a avea subclase, pe cand cuvantul root indica faptul ca acea clasa este radacina unui arbore dederivare.

11


12/25

Atat operatiile cat si atributele pot fi statice (afisate subliniat), deci nu vor apartine uneiinstante a clasei din care provine ci vor apartine chiar clasei, fiecare dintre instantele clasei avand

acces la acestea. Un atribut static mai poate fi denumit si o variabila a clasei putand fi accesat sifara sa existe vre-o instanta a unei clase, pe cand o operatie statica este folosita cu scopurigenerice cum ar fi crearea sau gasirea unui obiect acolo unde un obiect specific nu exista.

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,

instante ale celor doua clase). In UML o asociere este o legatura, o conexiune semantica intredoua clase. (! Priviti codul sursa generat pentru clasele Cerc si Punct pentru o mai buna intelegerea notiunii de asociere). O relatie de asociere trebuie sa fie o linie simpla daca ambele clase sunt

constiente de existenta celeilalte, sau o sageata orientata in cazul in care asocierea este cunoscutadoar de una dintre clase. Asocierile au mai fost intalnite si la diagramele use-case, insa intr-o

class-diagram mai poate aparea un tip de asociere numita asociere recursiva. O clasa poate ficonectata 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, aceste denumiri fiind de fapt rolurile jucate de instante ale claseiin cadrul asocierii.

Relatiile de mostenire Sunt niste relatii care pot aparea intre interfete sau clase, insa nu

si intre interfete si clase. Simbolul UML pentru o relatie de mostenire ar fi o linie cu un triunghialb in capatul dinspre superclasa. Clasa specializata (subclasa) mosteneste atributele, operatiile sichiar si asocierile clasei generale (superclasei).

12


13/25

Relatii de dependenta reprezinta o legatura semantica intre doua elemente alemodelului, unul dependent de cel pe care il vom numi independent. O schimbare in elementulindependent va afecta si elementul dependent.

Relatii de tip realization Relatii care exista doar intre interfete si clase. Asta inseamna

ca o clasa va mosteni toate operatiile interfetei, si bineinteles, va putea avea si alte operatiiproprii.

Packages Un package este un mecanism de grupare folosit pentru organizarea

elemntelor in grupuri de elemente avand o legatura semantica. Asadar package-urile sunt folositept structurarea modelului (un element poate fi continut doar de un singur package), iar in cadrul

unei class-diagram ele sunt folosite pt specificarea explicit a ierarhiilor. Asa cum clasele se pot plasa direct intr-un model, asa se pot situa si in interiorul package-urilor exprimand astfelinterdependentele existente intre anumite package-uri. Un package prezinta similaritati cu oagregare in sensul ca package-ul isi detine elementele; daca insa importa elemente din alte

package-uri vom spune ca avem de-a face cu o shared aggregation. Importarea dintr-un packageeste vazuta ca o dependenta, avand stereotipul .

Interfete sunt un fel de clase restrictionate in a contine doar operatii nu si atribute. Din

punct de vedere grafic o interfata este reprezentata printr-un dreptunghi cu doua compartimente(nume+operatii), avand stereotipul . Operatiile sunt abstracte si nu au nici oimplementare in cadrul interfetelor. Despre clasele care au o legatura cu o interfata vom spune caimplementeaza acea interfeta si ele vor fi nevoite sa implementeze aceste operatii (metode),

respectiv sa scrie codul acestora.

13


14/25

Action diagram

Scopul diagramele de activitate este acela de a modela actiunile (munca + activitati)implementate in operatii, in special in cele dintre doua sau mai multe clase si de a prezenta

rezulatele acestor actiuni.In proiectele in care sunt prezente use-cases, o diagrama de activitate poate modela un

use-case anume, la un grad de detaliere mai mare, insa aceste diagrame pot exista si independentde use-cases, si folosite pentru:

reprezentarea actiunilor executate odata cu o operatie (instanta implementarii uneioperatii)

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, referirea facandu-se la actori (muncitori),organizare, cursul activitatiiExemplu: modelarea unor functionalitati ale unui sistem sau subsistem.O diagrama de activitate se concentreaza asupra succesiunii in executie a actiunilor si

asupra conditiilor (trigger sau guard) care declanseaza aceste actiuni. De asemenea, o diagramade activitate se concentreaza asupra actiunilor interne ale activitatilor si nu asupra actiunilor careapeleaza activitatea in plin progres, sau asupra triggerelor ce declanseaza activitatea.

O actiune este facuta pentru a produce un rezultat. Implementarea unei operatii poate

poate fi descrisa ca un set de actiuni avand legatura, actiuni care mai tarziu vor f transformate incod.

Notatiile diagramelor de activitate sunt foart asemanatoare cu a celor de stari (statechartdiagram), de fapt conform specificatiilor UML o diagrama de activitate poate fi considerata ovarianta a unei diagrme de stari.

Asadar, la fel ca si o diagrama de stari, diagramele de activitate incep cu un Initial State

care este conectat de prima stare, printr-o tranzitie, iar activitatile care termina modelul suntconectate de un FinalState, la fel ca la diagramele statechart.Exemplu:

In diagramele de activitate, trecerea de la o stare la alta (stare = action-state) se faceatunci cand actiunea starii respective este terminata ( => nu este necesara specificarea unui

eveniment ca in diagramele statechart ).Specificatiile UML permit existenta unei singure stari initiala care sa aiba doar o singura

tranzitie care conecteaza starea initiala de o alta stare.Este posibil insa ca o activity diagram sa aiba mai multe stari finale, care sa reprezinte

terminarea unei ramuri logice, cu alte cuvinte o activitate poate sa se termine in diferite maniere.Pentru definirea unor astfel de ramuri logice se folosesc punctele de decizie. Acestea vor

avea atasate niste guard-uri, adica o conditie care la un moment dat poate lua valoarea Adevaratsau Fals. In functie de aceasta valoare de adevar activitatea va urma un curs sau altul.

Guardurile vor fi atasate de tranzitiile care pleaca din punctul de decizie si in mod normalla un moment dat numai unul dintre aceste guarduri trebuie sa aiba valoarea de adevar True.

Tranzitiile dintre stari au aceeasi sintaxa ca la statechart, exceptie facand evenimentele.Evenimentele pot fi atasate doar de tranzitiile care leaga punctul de start de primul action-state.Ele pot avea atasate conditii guard sau actiuni, insa atunci cand acestea lipsesc (de cele mai multeori) tranzitia va avea loc atunci cand toate activitatile din action-state se vor termina.

14


15/25

Cand tranzitiile sunt protejate de conditii guard, tranzitia se va face numai atunci candconditia va lua valoarea de adevar True.

Folosind un Fork, o tranzitie poate fi divizata in doua sau mai multe tranzitii. Acesteactiuni vor fi executate concurent, 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.Pentru a arata explicit unde sunt facute actiunile (in ce obiect), se folosesc asanumitele

swimlanes. Acestea se prezinta sub forma unor dreptunghiuri, iar activitatile corespunzatoareunor astfel de swimlanes vor fi plasate in interiorul dreptunghiurilor. Fiecarui swimlane ii este datun nume, care este pus in partea superioara a dreptunghiului.

\

15


16/25

Collaboration diagram

Collaboration diagrams descriu atat natura statica cat si natura dinamica a unui sistem.

O colaborare defineste rolurile care vor fi jucate atunci cand se executa subrutinele unuisistem. Aceste roluri vor fi jucate de instante ale claselor aflate in directa interactiune.

Diagramele de colaborare sunt o alta modalitate de reprezentare a interactiunilor si arelatiilor dintre obiecte. Spre deosebire de diagramele de tip sequence, ele nu se concentreaza pesuccesiunea 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.Un interes special il au in diagramele collaboration mesajele schimbate de obiecte

precum si scopul pentru care sunt schimbate aceste mesaje.La fel ca si o diagrama de secventa, o diagrama de colaborare poate fi folosita sa ilustreze

executia unei operatii, a unui use-cases sau pur si simplu sa ilustreze un scenariu de interactiuneintr-un sistem.

O diagrama de colaborare descrie un set de obiecte impreuna cu relatiile dintre eleprecum si interactiunile dintre acestea, adica felul in care respectivele obiecte coopereaza pentru adefini functionalitatea unui sistem sau subsistem. Este foarte utila modelarea interactiunilorpentru un sistem in timp real, 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 poatereprezenta mai mult de un fir de executie, precum si o transmitere simultana a mai multor mesaje.

Diagramele de colaborare arata obiecte si legaturile dintre acestea, precum si felul in caremesajele sunt trimise intre obiectele conectate (prin legaturi). Obiectele sunt desenate la fel ca si

clasele (in forma restransa), insa numele obiectului este subliniat (numele simbolului obiect).Legaturile arata foarte mult cu asocierile insa le lipseste multiplicitatea.

O diagrama de colaborare incepe cu un mesaj care initiaza intreaga interactiune saucolaborare. 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 pentrumesajul respectiv. Mesajul acesta va fi de cele mai multe ori un apel de procedura (operatie), cain figura de mai jos.

16

Collaboration

Role

Class

rolename

rolename

rolename

rolename


17/25

Un actor trimite un mesaj pentru printare catre un computer. Computerul trimite un mesajde printare serverului, care la randul lui va trimite un mesaj de imprimare catre imprimanta (dacaaceasta este libera).

Mesajele sunt numerotate astfel:

- primul mesaj, cel care porneste o secventa intreaga de mesaje va fi numerotat cu 1- mesajul 1.1 este primul mesaj care decurge din rezolvarea primului mesaj

- mesajul1.2 este urmatorul- mesajele trimise in paralel, adica cele concurente pot fi descrise folosind litere in cadrul

expresiei numerice care exprima succesiunea mesajelor. De exemplu 2.1.a si 2.1.b vor fifolosite pentru doua mesaje care vor fi trimise in paralel.

Un Link este o conexiune dintre doua obiecte care colaboreaza. Mesajele (stimulii) vor fipozitionati de-a lungul acestora.

Rolul jucat de un obiect intr-o colaborare va fi aratat la capetele link-urilor. Unuiastfel de rol i se pot atasa diferite stereotipuri cum ar fi:

- global: specifica faptul ca instanta respectiva este vazuta in intregul sistem si poate fiapelata folosind un nume cunoscut oriunde in sistem

- local: specifica faptul ca instanta respectiva este vazuta deoarece este o variabila localaintr-o operatie.

- parameter: specifica faptul ca instanta respectiva este vazuta deoarece este un parametru aunei operatii

- association: specifica faptul ca instanta respectiva este vazuta doar de catre obiecteleaflate in asociere

- self: specifica faptul ca instanta respectiva este vazuta doar de catre ea insasiObiectelor create in timpul unei colaborari vor avea constrangerea {new}, iar cele care

sunt distruse in timpul colaborarii vor avea constrangerea {destroyed}. Obiectele care sunt sicreate si distruse in cadrul aceleiasi colaborari vor avea constrangerea {transient}care esteechivalenta cu {new}{destroyed}.

Obiectele, cele care joaca rolurile din digrama de colaborare, vor fi etichetate cu nume de

clase, de obiecte sau cu ambele. Numele claselor sunt precedate de :, iar fiecare mesaj dindiagrama are un numar care va indica succesiunea acestora. Primul mesaj va fi numerotat cu 1, iar

mesajele de pe acelasi nivel (trimise in timpul aceluiasi apel) au acelasi prefix, dar vor continuacu un sufix diferit in ordinea in care mesajele vor fi transmise.

Exista mai multe tipuri de mesaje si anume:- simple: arata cum controlul este pasat de la un obiect la altul fara a se da vre-un detaliu

despre comunicare; acest tip de mesaj este folosit este folosit cand nu se cunosc detaliidespre comunicare sau cand aceste detalii nu sunt considerate relevante in diagrama la

care se lucreaza; mesajele simple mai sunt folosite pentru a arata faptul ca controlul estedat inapoi de la obiectul care a primit un mesaj sincron la cel care a initiat acel mesaj.

- sincrone: similare cu un apel al unei operatii; operatia care primeste mesaul isi termina toateoperatiile (inclusiv transmiteea de alte mesaje), inainte ca obiectul care a initiat primul mesaj sa-si

continue executia; aceasta reintoarcere catre primul obiect poate fi reprezentata ca un mesaj saupoate fi considerata implicita la terminarea operatiei care se ocupa de mesajul transmis.

- asincrone: sunt folosite acolo unde nu exista o reintoarcere explicita in cadrul obiectuluicare initiaza mesajul, acesta continuandu-si executia dupa transmiterea mesajului, fara saastepte rezultatul operatiilor care se vor executa odata cu transmiterea mesajului; acest tipde mesaj este folosit in sistemele in timp real unde obiectele se au o executie concurenta.

Un mesaj simplu si unul sincron pot fi combinate pentru a arata ca la transmiterea mesajului,returnarea controlului are loc aproape instantaneu.

Adnotari cu privire la timp pot fi adaugate diagramelor de colaborare, insa nu asa clar caintr-o diagrama de tip sequence. Aceste adnotari vor fi de fapr notite sau constrangeri atasate

diferitelor elemente din diagrama.

17


18/25

Diagrama de colaborare din figura de mai sus arata interactiunile care au loc cand unsenzor al unei alarme detecteaza ceva. Acesta trimite un semnal de alarma asincron catre Cell

Handler. In continuare Cell Handler trimite in paralel semnale (mesaje) asincrone paralele catretoate alarmele (in acest caz, un telefon si un alarma sonora) si un semnal de tot asincron catre

System Handler. System Handler folosind Superviser, va trimite un stimul pentru declansareaalarmei interne, iar apoi va scrie evenimentul intr-un fisier log. O diagrama de colaborare

furnizeaza o poza buna a ambelor structuri a obiectelor implicate si interdependenta lor.Un obiect activ se executa deodata cu thread-ul sau de control.

Un actor de la un anumit etaj apasa un buton. Elevator control creeaza o noua sarcina pt

lift pe care o introduce in coada liftului. Obiectul elevator este activ, ruleaza concurent si isiextrage noile sarcini din coada sa.

18


19/25

Sequence Diagram

O diagrama de secventa este o diagrama ce descrie structura dinamica a unui sistemaratand interactiunile dintre instantele unor clase (obiecte) in momentul rularii programului

(functionarii sistemului), oferind o harta a modului de transmitere a mesajelor intre obiecte intimp (=> se modeleaza operatiile care vor trebui incluse in clasele sistemului precum si

evenimentele suportate de clase).Frecvent acest tip de diagrame vor fi situate sub Use-Cases sau sub diferite componente

pentru a ilustra un scenariu (nu un algoritm), sau niste succesiuni de pasi care sunt parcursi laaparitia unui eveniment. O astfel de diagrama va arata ce obiect initiaza activitatea intr-un sistem,

ce procese si schimbari vor avea loc intern in cadrul sistemului si ce date de iesire vor fi generatein urma interactiunilor dintre obiecte.

Asadar o diagrama de secventa va reprezenta un scenariu Use Case (sau o parte a unuiscenariu Use Case) sau un curs al evenimentelor, concentrandu-se pe succesiunea in timp a

interactiunilor din timpul executiei, care este determinata prin citirea diagramei de sus in jos.O diagrama de secventa are doua dimensiuni:

- dimensiunea verticala: arata succesiunea mesajelor/apelurilor ordonate in functie de momentulin care apar (functie de timp)

- dimensiunea orizontala: arata obiectele catre care sunt trimise mesajele (Obiectele implicatesunt 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. myReportGenerator : ReportGenerator).

Ca notatie UML, o diagrama de secventa va consta dintr-un set de obiecte, fiecare avando linie verticala punctata care reprezinta viata obiectului respectiv (linia vietii). 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.

Mesajele (stimulii), sunt desenate ca fiind sageti trasate de la un obiect la altul. Daca oinstanta a unei clase trimite un mesaj (stimul) unei alte instante, se va desena o sageata (deschisa)

orientata spre instanta care va primi mesajul.Numele mesajului (stimulului) precum si a actiunii care se va executa vor fi plasate

deasupra acestei sageti. Actiunea executata este de cele mai multe ori o operatie implementata incadrul clasei obiectului care primeste mesajul. Daca aceasta operatie returneaza o valoare care

este importanta in desfasurarea executiei programului, se poate desena o sageata punctata,orientata spre obiectul apelant (numita return stimulus in Poseidon).

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. Return stimuli Reprezinta ceea ce se returneaza in urma unui call stimulus.

Create stimuli Folosit pentru a crea un nou obiect la un anumit dat in cadrul secventei deinteractiuni.

Destroy stimuli - Folosit pentru a distruge un obiect la un anumit dat in cadrul secventei deinteractiuni. Linia vietii acelui obiect care va fi distrus se va termina printr-o cruce in momentultrimiterii stimulului.

19


20/25

Component and Deployment Diagrams

Majoritatea uneltelor Case existente permit crearea unei astfel de diagrame sub

denumirea de deployment diagram, ArgoUML, nici Poseidon nefacand exceptie de la aceasta. InPoseidon 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 astfel de diagrama ofera o vedere din punct de vedere fizic asupra sistemului. Scopul ei

este de a arata dependentele pe care software-ul dezvoltat le are cu alte componente software dincadrul sistemului (Ex: biblioteci de functii). O diagrama de componenta poate reprezenta sistemul

la un nivel superior (high-level), ilustrand numai principalele componente la un nivel de detalierefoarte mic, sau la un nivel inferior (low-level) unde vor fi ilustrate componentele pana la nivelulpackage-urilor.

Diagramele de componenta sunt foarte folositoare in cazul in care se lucreaza la un

proiect cu un numar relativ mare de echipe de dezvoltare. Ele ajuta la modelarea si apoiidentificarea componentelor software si a interfetelor acestora. O data ce interfetele au fostdefinite si acceptate de echipe este mult mai usor de organizat efortul de dezvoltare alsubechipelor.

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. Links sunt folosite pentru conectarea obiectelor sau instantelor de noduri.

Dependencies acestea exista intre diferite componente si pot fi specificate utilizand stereotipi(predefinite sau nu). Associations - sunt folosite pentru a ilustra relatiile de comunicare dintre noduri. La fel cadependentele si asocierile pot fi specificate folosind stereotipi.

Objects, Classes, Interfaces - componentele si nodurile pot include obiecte, clase sau interfete.Dupa un timp, 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 subforma unor componente. Componentele sunt de fapt fisierele existente in mediul de dezvoltare

folosit pentru constructia unui system. Ele sunt blocurile care alcatuiesc sistemul distribuit pediferite alte elemente hardware (aceste elemente hardware pot fi si computere diferite). De faptele sunt artefacte de nivel inalt cum ar fi java beans, dll-uri, ocxs-uri si alte produse software, demulte ori compuse din alte elemente mai simple cum ar fi clase si functii din biblioteci.

Componentele mai pot fi vazute si ca implementarea in arhitectura fizica a unui sistem aconceptelor si functionalitatilor definite in arhitectura logica (clase, obiecte, diferite relatii si

colaborari). Fiecare componenta va oferi servicii altor componente (numite clienti), acesteservicii numite contracte facandu-se de obicei prin intermediul interfetelor.

Exemple de componente:

ActiveX Control: set de tehnoloogii Microsoft care ofera continut interactiv pt World

Wide Web (efecte multimedia, obiecte interactive) Dll (dynamic link library)

JavaBean (suport pt servere de aplicatii)

Pagini Web

20


21/25

O componenta software poate fi:

source component (Compile-Time Components): un fisier continand cod sursa in care suntimplementate una sau mai multe clase; o astfel de componenta are un inteles la momentulcompilarii (compile time), celelate tipuri de componente fiind generate de componente de

acest tipPentru Compile-Time Components se pot folosi urmatoarele stereotipuri:

- : fisier continand cod sursa- : o reprezentare a unei pagini web

- : 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; o astfel de componenta poate fi un fisier cu cod obiect(obj), un fisier static sau dinamic de functii (library files) care are un inteles la link-time sauin cazul unei librarii dinamice la run-time (o astfel de biblioteca este incarcata de ocomponenta executabila doar in momentul rularii)

Pentru Link-Time Components se pot folosi urmatoarele stereotipuri:- : simplu proces- : 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 run-time), sau cateodata direct din Compile-Time Components (ex. 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:

- : reprezinta un fisier executabil- : o reprezentare a unui tabel dintr-o baza de date folosit drept

componenta la run-time

21


22/25

Sa presupunem ca dorim sa construim un software pentru muzica de pe CD-uri (unplayer) a carui interfata, simpla ar include doar butoanele obisnuite . Atunci am avea urmatoareadiagrama de componenta:

In UML o componenta este ilustrata sub forma unui dreptunghi uneori avand o elipsa plus inca doua mici dreptunghiuri in stanga. Componentele sunt niste tipuri, insa numai

componentele executabile pot avea instante (atunci cand programul pe care-l reprezinta este

executat de compilator ).Principiile designului de componente:

nu trebuie sa existe cicluri de forma A B C A unde sageata reprezinta o relatiede 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 elementsoftware)

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 suferimodificari)

componenta trebuie sa fie suficient de abstracta pentru ca sa poata fi extinsa fara a-I fi

afectata stabilitatea.In timp, construind astfel de componente in cadrul unei arhitecturi, se poate ajunge la o

structura arhitecturala reutilizabila care va putea fi folosita cu succes in cadrul altor si altorsisteme.

O component diagram arata felul cum sunt organizate componentele software (source,binary, executable), relatiile dintre si dependentele existente intre acestea, felul in care comunicaetc. O astfel de diagrama este folosita de obicei pentru prezentari de marketing sau rezumate aarhitecturii unui sistem.

O sageata punctata intre doua componente inseamna ca o componenta are nevoie de oalta pentru a fi definite complet. O astfel de dependenta intre o source component A si o sourcecomponent B inseamna ca, o schimbare in B necesita o recompilare si a lui A. Dacacomponentele 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.O componenta poate sa implementeze una sau mai multe interfete care sa poata fi vazute

de alte componente (=>publica comportamentul componentei respective). Aceste interfete pot fidefinite la nivel cod (ex: interfete Java) sau binary, folosite la run-time (ex. OLE).

22


23/25

Legatura unei componente cu o anumita interfata poate fi reprezentata in doua moduri,dupa felul acestei legaturi. Componenta ofera de obicei o interfata si in acest caz se va folosinotatia tip lollypop. Incepand cu UML2 a fost introdusa simbolul de socket pentru a indica faptulca este nevoie de implementarea unei interfete. Acest simbol poate fi considerat un stereotip

vizual pentru o dependenta. (in locul lui poate fi folosita o dependenta obisnuita cu stereotipul).

Un port (notatia UML = patrat mic), va fi o caracteristica a unei componente ce specificaun punct de interactiune a componentei cu mediul extern. Aceste porturi care pot avea si un numevor putea suporta o comunicatie unidirectionala sau bidirectionala, dupa caz.

Nu este nevoie sa fie folosite toate interfetele unei componente.

Figura de mai jos ilustraza patru componente: Reporting Tool, Billboard Service,Servlet 2.2 API, and JDBC API. Existenta sagetilor care pleaca de la componenta Reporting Toolcatre componentele Billboard Service, Servlet 2.2 API, and JDBC API inseamna ca ReportingTool este dependent de aceste trei componente.

O component diagram va arata o componenta numai sub forma unui tip, deci daca avem

nevoie de reprezentarea unei instante a unei componente vom trebui sa folosim o deploymentdiagram.

O deployment diagram sa o network diagrams cum i se mai spune descrie felul cumcomponentele sunt repartizate pe diferitele computere existente in cadrul unui sistem. Notatiile

dintr-o deployment diagram includ elementele notationale folosite intr-o component diagram,avand insa si cateva adaugari cum ar fi conceptul de nod care reprezinta de fapt o masina (reala

sau virtuala). Scopul unei astfel de diagrame este de a ilustra unde vor rula (dpdv fizic) diferitelecomponente si cum vor comunica una cu alta, asadar s-ar putea spune ca o deployment diagrammodeleaza sistemul la run-time.

Cel mai simplu exemplu de deployment diagram ar fi diagrama care descrie un PC:

23


24/25

Diagrama de tip deployment din figura de mai sus arata faptul ca userul acceseazaReporting Tool folosind un browser care ruleaza pe o masina locala si se conecteaza la ReportingTool prin intranetul companiei folosind protocolul HTTP. Aceasta ruleaza (dpdv fizic) peserverul de aplicatii.

Diagrama arata componenta Reporting Tool desenata inauntul componentei IBM

WebSphere, care la randul ei este desenata inauntrul nodului care reprezinta serverul de aplicatii.Reporting Tool se conecteaza la baza sa de date folosind limbajul Java si interfata IBM JDBC

API, care apoi comunica cu baza de date Reporting aflata pe serverul MySQL Server folosindinterogari SQL. Componenta Report Tool comunica folosind SOAP over HTTPS cu BillboardService.

24


25/25

Bibliografie:

1) http://www.ici.ro/RRIA/ria2004_3/art08.htm2) http://www.sparxsystems.com.au/uml-tutorial.html3) http://www.uml.org/4) http://www.visual-paradigm.com/5) http://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in

%20UML.pdf

6) http://funinf.cs.unibuc.ro/~gheorghe/curs/metDezvSoft/lec/l05four.pdf7) http://cs.ubbcluj.ro/~vcioban/Informatica/Anul3/SIPP/Esit/curs/Modelare

%20OO%20UML%20GRAPPLE.doc

8) http://thor.info.uaic.ro/~adrianaa/uml/9) http://www.techit.ro/tutorial_uml_1.php10) http://www.techit.ro/tutorial_uml_2.php11) http://www.techit.ro/tutorial_uml_3.php

25
http://www.ici.ro/RRIA/ria2004_3/art08.htmhttp://www.sparxsystems.com.au/uml-tutorial.htmlhttp://www.uml.org/http://www.visual-paradigm.com/http://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in%20UML.pdfhttp://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in%20UML.pdfhttp://funinf.cs.unibuc.ro/~gheorghe/curs/metDezvSoft/lec/l05four.pdfhttp://cs.ubbcluj.ro/~vcioban/Informatica/Anul3/SIPP/Esit/curs/Modelare%20OO%20UML%20GRAPPLE.dochttp://cs.ubbcluj.ro/~vcioban/Informatica/Anul3/SIPP/Esit/curs/Modelare%20OO%20UML%20GRAPPLE.dochttp://thor.info.uaic.ro/~adrianaa/uml/http://www.techit.ro/tutorial_uml_1.phphttp://www.techit.ro/tutorial_uml_2.phphttp://www.techit.ro/tutorial_uml_3.phphttp://www.ici.ro/RRIA/ria2004_3/art08.htmhttp://www.sparxsystems.com.au/uml-tutorial.htmlhttp://www.uml.org/http://www.visual-paradigm.com/http://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in%20UML.pdfhttp://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in%20UML.pdfhttp://funinf.cs.unibuc.ro/~gheorghe/curs/metDezvSoft/lec/l05four.pdfhttp://cs.ubbcluj.ro/~vcioban/Informatica/Anul3/SIPP/Esit/curs/Modelare%20OO%20UML%20GRAPPLE.dochttp://cs.ubbcluj.ro/~vcioban/Informatica/Anul3/SIPP/Esit/curs/Modelare%20OO%20UML%20GRAPPLE.dochttp://thor.info.uaic.ro/~adrianaa/uml/http://www.techit.ro/tutorial_uml_1.phphttp://www.techit.ro/tutorial_uml_2.phphttp://www.techit.ro/tutorial_uml_3.php

analiza obiectuala a sistemelor in format ice ( aplicatie uml )

Documents