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

Analiza obiectuala a sistemelor informationale ( aplicatie UM !

"#$$

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

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

Use-case Diagram ..

pg.5 Class Diagram ....pg. !c"ion diagram .. pg. #2 Colla$ora"ion diagram ...pg. #% &e'uence Diagram .....pg. #( Componen" and Deplo)men" Diagrams ...pg. # *i$liografie ..pg. 2+

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

module cat mai mici a produsului pentru usurinta implementarii) implementarea (scrierea efecti"a a codului) si testarea. #n cadrul lucrului la un proiect software sunt implicate mai multe persone fiecare are atri$u%ii complementare celorlal%i. &e pot distinge mai multe specialitati: utilizatori ' exploatatorul softului( efi de proiect ' totdeauna tre$uie s) existe cine"a cu aceast) func%ie( analiti de sistem ' execut) modelul informatic al aplica%iei( proiectani de sistem ' execut) ar*itectura programului aplica%iei( programatori ' execut) modulele( ingineri de test ' "erific) ceea ce s'a creat. +cti"itatea ,n ec*ip) este puternic interacti") comunicarea dintre mem$rii personalului cu specialitati diferite facandu'se de o$icei prin intermediul formularelor si rapoartelor care de o$icei de"in greu de urmarit din pricina formatarii sau a lipsei de organizare a acestora sau c*iar a omiterii anumitor detalii despre o anumita componenta (modul). #n cadrul fazei de proiectare se construieste de o$icei un modul al proiectului la care se lucreaza. -odelarea este o parte esentiala a unui proiect software el .uc/nd un rol analog cu proiectul arc*itectural al unei cladiri de mari dimensiuni. 0olosind un model ce'i responsa$ili pentru succesul sau esecul unui proiect se pot asigura inca dinainte de inceperea scrierii codului ca : functionalitatea proiectului "a fi corecta si completa toate necesitatile utilizatorului final "or fi satisfacute designul programului "a satisface cerintele de scala$ilitate ro$ustete extenda$ilitate etc. #n cadrul operatiunii de modelare se pleaca de la premisa ca sistemele software sunt complexe de aceea a"em ne"oie de o multitudine de "iziuni simple ale acestora asfel incat in final sa stapanim complexitatea. 1rincipalele astfel de "iziuni sau "ederi sunt: 2se'case "iew Logical "iew 3omponent "iew 3oncurrenc4 "iew 5eplo4ment "iew Lim$a.ul 2-L este o te*nica folosita pentru descrierea specificarea si documentarea functiilor unei aplicatii in timpul fazei de design. 2-L este produsul a multi ani de munca a mai multor companii cu renume in lumea #6 dintre care amintim &un -icro &4stems 7racle 3orporation 8ewlett'1ac9ard 3ompan4 #:3orporation &+1 su$ patrona.ul si sponsorizarea concernului 7-; (7$.ect -anagement ;roup fondat in 1<=<). 2-L este un lim$a. grafic creat pentru "izualizarea specificarea 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. 3*iar daca 2-L nu poate garanta succesul unui proiect el constituie o unealta foarte importanta reprezentand de fapt o colectie de practici ingineresti care s'au do"edit de succes in modelarea de sisteme mari si complexe.

2nul din principalele scopuri ale dez"oltatorilor lim$a.ului 2-L a fost acela de a crea un set de notatii semantice care sa se adreseze tuturor tipurilor de proiecte ar*itecturale complexe indiferent de domeniu (industrial software mar9eting constructii etc.).

2-L ofera un model standard de a scrie documentatie de sistem functii de sistem precum si alte lucruri concrete cum ar fi declaratii intr'un anumit lim$a. de programare sc*eme ale $azelor de date si componente software reutiliza$ile. 2nified -odelling Language (2-L) este un lim$a. de modelare si nu o metoda sau un proces. 2-L are notatii specifice si reguli gramaticale $ine precizate pentru construirea modelelor software. ?xista o $ogata colectie de elemente notationale grafice suportate de 2-L. ?xista o serie de elemente care descriu clase componente noduri acti"ititati wor9 flow o$iecte stari dar exista si elemente grafice care a.uta la modelarea relatiilor intre elementele amintite. 2-L suporta notatii pentru extinderea puterii lim$a.ului de modelare (referirea se face aici la elementele de tip stereot4pe si constraints) asigurand a"anta.e semnificante ingineriei software a.utand la construirea de modele rigurase usor de urmarit si intretinut care sa suporte intregul ciclu de dez"oltare software. -odelele si diagramele create au o importanta influenta asura felului in care o anumita pro$lema este a$ordata si a felului in care o anumita solutie prinde forma. 1rin a$stractizare atentia se concentreaza asupra detaliilor semnificante ignorandu'le pe celelalte. +ceasta este cauza pentru care: fiecare sistem complex este a$ordat printr'un set de "ederi diferite ale unui model. (o singura "edere nu este suficienta) fiecare model poate fi reprezentat cu un grad diferit de fidelitate cele mai $une modele sunt cele inspirate din realitate ?ste necesara constructia unui model pentru sistemele complexe deoarece mintea umana nu poate acoperi toate detaliile unui astfel de sistem. 3u cat complexitatea unui sistem creste cu atat creste si importanta folosirii unei $une te*nici de modelare si implicit a unui lim$a. riguros de modelare cum este 2-L. 2-L un lim$a. de modelare "izual nu a fost creat si nu este in masura sa inlocuiasca un lim$a. de programare insa cu a.utorul lim$a.ului 2-L se poate modela orice tip de aplicatie care ruleaza pe orice com$inatie de *ardware sistem de operare sau tip de retea. 0lexi$ilitatea lui permite modelarea aplicatiilor distri$uite ce folosesc orice tip de middleware de pe piata iar datorita faptului ca o$iectele si clasele sunt definite drept concepte fundamentale un model construit in 2-L "a putea fi relati" usor de implementat intr'o serie de lim$a.e de tip 771 (3@@ Aa"a 3B). 6re$uie precizat insa ca lim$a.ul 2-L se poate folosi si pentru a modela aplicatii non' 771 in lim$a.e precum 3o$ol 0ortran sau Cisual :asic . 5esignul software nu este un simplu proces automat de transformare a unei specificatii in alta. ?l implica si luarea unor decizii complexe care se "or repercuta asupra produsului final. 2neltele pentru design cele care a.uta designerii in luarea deciziilor sunt un mi.loc important de a creste producti"itatea si calitatea designurilor software rezultate. +stfel au aparut uneletele 3+&? (3omputer +ided &oftware ?ngineering) care se gasesc in numar foarte mare si au grade diferite de utiliza$ilitate. 5in ele se pot distinge: Dational Dose +rgo2ml 1oseidon (;entleware). -oti"e pentru care +rgo2ml (aparut in1<<=) se distinge din multitudinea de unelte 3ase: ofera mi.loacele necesare pt cresterea producti"itatii realizarii softurilor de tip 771 foloseste doar standarde desc*ise (open standards) ceea ce inseamna in primul rand posi$ilitatea unei cola$orari cu alte aplicatii care folosesc aceste standarde. 1rintre aceste standarde folosite se afla: in primul rand 2-L'ul apoi E-L -etadata #nterc*ange (E-#) &cala$le Cector ;rap*ics (&C;) 7$.ect 3onstraint Language (73L).

 implementeaza toate specificatiile lim$a.ului 2-L 1.3. fiind singura unealta care implementeaza meta'modelul 2-L exact asa cum a fost specificat este o aplicatie 1FFG Aa"a deci se $ucura de tote calitatile unui produs Aa"a este open'source (in plina dez"oltare) #n plus +rgo2ml a fost inspirat si a tinut cont de cele trei teorii din psi*ologia cogniti"a: reflection'in'action: designerii unor sisteme complexe nu concep un design in totalitatea sa. 5e aceea ei tre$uie sa construiasca un design partial sa'l e"alueze e"entual sa'l modifice pana cand "or fi pregatiti sa extinda acel design partial ( Htirania paginii al$eI este un efect similar) design oportunistic: descompunerea ierar*ica este o strategie uzuala in designul sistemelor complexe . 6otusi in practica s'a o$ser"at ca designerii lucreaza la module alese oarecum oportunistic functie de efortul mental pe care tre$uie sa'l depuna la un moment dat generare si explorare: in prima faza sunt generate noi idei care mai apoi in faza a doua "or fi explorate iar implicatiile lor "or fi e"aluate #n figura de mai .os sunt prezentate toate diagramele precizate in specificatiile 2-L:

5iagramele 2-L

Class diagrams: descriu clasele pac9age'urile proprietatile lor si diferitele relatii care pot aparea intre acestea. ,$-ec" diagrams: descriu un anumit scenariu in loc de clase ca la class diagrams "or aparea o$iecte instante ale acestor clase. Use-case diagrams: descriu use cases actorii implicati (cei care interactioneaza cu sistemul) pus diferitele relatii existente.

&e'uence diagrams and Colla$ora"ion diagrams: descriu sec"enta de mesa.e sc*im$ate de o$iecte la run'time. &"a"echar" diagrams: prezinta starile pe care le pot a"ea o$iectele in cadrul unui sistem. !c"i.i") diagrams: prezinta algoritmi sau data'flow. Componen" diagrams: descriu componentele implementate (?x: source J o$.ect files) Deplo)men" diagrams: descriu felul cum componentele sunt repartizate pe diferitele computere.

Use-case Diagram
2n caz de uz (use case) este o te*nica de modelare folosita pentru a descrie functionalitatea unui sistem deci ce ar tre$ui sa faca un nou sistem sau ce face de.a un anumit sistem. &'ar putea spune c*iar ca o diagrama use-case descrie ceea ce face un sistem din punctul de "edere al unui o$ser"ator extern aceasta descriere fiind independenta de implementare. +desea o astfel de diagrama este folosita in etapele preliminarii a procesului de design pentru a colecta cererile clientului cu pri"ire la proiect. +sadar constructia unui model use-case reprezentat printr'o diagrama use-case (sau mai multe) se face de o$icei dupa lungi discutii intre dez"oltatori si clienti pe $aza specificatiilor asupra carora au cazut cu totii de acord. 2n model use-case "a descrie si "a tre$ui sa surprinda felul in care un actor "a folosi un anumit sistem. 1entru a crea un model use'case tre$uie parcursi mai multi pasi si anume: definirea sistemului identificarea actorilor si a use'case'urilor descrierea use'case'urilor definirea relatiilor dintre use'cases iar in final "alidarea modelului. 5escrierea use'case'urilor se face fie printr'un text scris fie prin conceperea unei diagrame de acti"itate. 3el mai important scop al unei diagrame use'case este de a a.uta dez"oltatorii de sisteme software sa "izualizeze cerintele functionale ale unui astfel de sistem sau unitati de sistem. 5intre use'cases actori si dependente actorii sunt pentru programatori cele mai neimportante elemente ale unei diagrame use'case. Delatiile sunt de fapt cele mai importante deoarece acestea le sugereaza care dintre use'case'uri sa fie implementat prima data. 5e regula se incepe cu use' case'ul cu cele mai multe dependente deoarece alte use'case'uri depind de acesta. 5in punct de "edere grafic o diagrama use'case este un graf a"and drept noduri actori si use' cases iar drept muc*ii diferite relatii intre aceste elemente. !c"or este o entitate externa (persoana sau ec*ipament) care are un interes in a interactiona cu sistemul deci "a face un sc*im$ de informatii cu sistemul (sc*im$a mesa.e). 2n actor reprezinta un rol nu un utilizator indi"idual al sistemului. +sadar un actor reprezinta o clasa nu o instanta a"and stereotipul KKactorLL si deci poate a"ea atat atri$ute cat si operatii ($e*a"iours) precum si o documentatie in care sunt descrise acestea.

&terotipii extind "oca$ularul 2-L sunt folositi la etic*etarea artefactele 2-L pentru a indica ca acestea apartin unei anumite categorii sau pur si simplu pentru a reda mai multe informatii despre artefactul 2-L. 2n actor are un nume iar numele acestuia tre$uie sa reflecte rolul actorului. +ctorii pot fi categorisiti in actori primari si secundari sau in actori acti"i (cel care initiaza use'case'ul) sau pasi"i (doar participa intr'un use'case). #ntr'o diagrama actorii pasi"i se pot deose$i de cei acti"i dupa sensul asocierilor. #dentificarea actorilor din cadrul unui sistem se face raspunzand la urmatoarele intre$ari: 1. 3ine "a folosi principalele functionalitati ale unui sistemM (actori primari) !. 3ine are ne"oie de spri.in in realizarea indatoririlor zilniceM (useri) 3. 3ine "a tre$ui sa intretina administreze si sa mentina in stare de functionalitate sistemulM(actori secundari) 4. 3u ce alte sisteme "a tre$ui sistemul nostru sa interactionezeM(sistem N alt computer sau alte aplcatii de pe computerul pe care se dez"olta sistemul) 5. 3ine are un interes in rezultatele pe care le "a produce sistemulM

Use cases O +cti"itati semnificante pentru sistem (nu tre$uie sa fie mai multe de 3F( daca se depaseste numarrul proiectul se "a sparge in mai multe $ucati). 5e fapt un use-case reprezinta o functionalitate completa a unui sistem asa cum este "azuta de catre un actor. #dentificarea use'case'urilor ce tre$uiesc modelate intr'un sistem se face raspunzand la urmatoarele intre$ari: 1. 3e "rea un actor de la sistemM 3e anume "rea el sa facaM !. +re ne"oie un actor sa citeasca creeze distruga modifice sau depoziteze "re'un tip de informatie in cadrul sistemuluiM 3. +ctorul tre$uie sa fie anuntat de e"enimentele din sistem sau actorul tre$uie sa anunte ce"a sistemuluiM 4. -unca zilnica a unui actor poate fi simplificata prin adaugarea de functii noi sistemuluiM /rincipalele carac"eris"ici ale unui use-case sun": 1. este initiat intotdeauna de catre un actor !. intoarce o "aloare catre un actor 3. este complet ("aloarea finala este produsa) 2n use'case tre$uie sa ai$a un nume care de regula este o fraza care descrie cat mai $ine functinalitatea use'case'ului. La fel ca si actorii0 un use-case es"e o clasa si nu o instanta aceasta clasa descriind functionalitatea ca un intreg incluzand posi$ile alternati"e erori si exceptii care pot sa apara in timpul executiei unui use'case. 7 instanta a unui use'case poarta numele de scenariu reprezentand de fapt un caz de folosinta a sistemului.

12"ension /oin"s ' ?ste o referinta catre o locatie dintr'un use'case unde se pot insera sec"ente din alte use'cases (fiecare extension point are un nume unic in cadrul use'case' ului).

3ela"iile care se po" modela in"r-o diagrama use-case sun": 4enerali5are O ?ste o relatie intre un element parinte (mai general) si un element fiu (mai specific) care este perfect compati$il cu elementul parinte adaugand insa si elemente aditionale.

;eneralizarea este folosita pentru actori use'cases clase pac9age'uri etc deci pentru tipuri niciodata pentru instante. Delatiile de generalizare sunt numite cateodata relatii Heste unPoI (H7 masina este "e*icul NL generalizarea masinii este un "e*iculI) si sunt folosite pt a descrie comportamentul comun al unui anumit numar de elemente. ?lementul specializat (fiu) mosteneste comportamentul elementului general (superclasa sau parintele) extinzand intr'un anumit fel acest comportament. 7 astfel de relatie poate a"ea un nume si un stereotip. ?xemplu de generalizare: un proiect este un proiect intern sau extern. !ssocieri: +par intre diferite elemente (?x: actori si use'cases) si pot fi na"iga$ile in am$ele directii intr'o singura directie sau nena"iga$ile. 7 asociere intre doua elemente ar insemna (s'ar traduce) ca elementele aflate intr'o relatie de asociere Hstiu una de altaI Hsunt conectateI sau Hpentru fiecare E exista un Q (sau mai multi de Q asta depinzand de multiplicitate)I. Deprezentarea grafica a unei asociatii este o linie simpla care poate a"ea si un stereotip. #n cadrul diagramei use case'urile sunt conectate de actori cu a.utorul asociatiilor care arata cine cu cine comunica precum si care este actorul care initializeaza un use'case. Lipsa unei sageti indica faptul ca comunicarea se face in am$ele directii. 7 asociere poate a"ea si ea un nume care este de preferinta sa fie ales astfel incat sa descrie cat mai $ine in ce consta respecti"a asociere. 7 asociere are doua capete. -ultiplicitatea unui capat al asociatiei reprezinta numarul posi$il de instante asociate cu o singura instanta a celuilalt capat. Rumarul respecti" poate fi un singur numar sau o serie de numere. 5e exemplu poate fi un singur client pentru o comanda dar un client poate face oricate comenzi. #ata principalele multiplicitati folosite: F..1 zero sau o instanta F..S nici o limitare la nr. de instante 1 exact o instanta 1..S cel putin o instanta !ggrega"ion' 7 asociatie in care un element este HparteI a unui HintregI reprezentat de celalalt element. ?xista mai multe tipuri de agregari cum ar fi: 1. agregari fixe (au un nr. presta$ilit de componente) !. agregari "aria$ile (numar "aria$il dar finit de componente) ?x: liste "ectori 3. agregari recursi"e ?x: ar$orii $inari contin ar$ori $inari Composi"ion O ?ste o puternica forma de agregare in care elementul HparteI este distrus automat in momentul distrugerii elementului HintregI. #n cadrul unei agregari elementul parte mai exista si dupa ce elementul Hintreg este distrusI. 3a si la agregare pot fi compozitii fixe "aria$ile si recursi"e. Dependen"e O 1ot 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 deci depinde de acel element. 2rmand sensul dependentei o sc*im$are in specificatia unui element ar putea afecta si pe elementul aflat in relatie de dependenta cu primul. +cestea au de o$icei un stereotip pentru o mai $una definire a rolului dependentelor. ?xista doua tipuri speciale de dependente: KKextendLL si KKincludeLL.

12"end rela"ionship O 7 relatie unidirectionala intre doua use'cases. 7 relatie de tip extend intre : si + (: + N use'cases) inseamna ca caracteristicile lui : pot fi incluse in +.

6nclude rela"ionship ' 7 relatie unidirectionala intre doua use'cases. 7 astfel de relatie intre use'case'urile + si : inseamna ca inseamna ca caracteristicile lui : vor fi intotdeauna incluse in + .

6n "impul crearii unei diagrame use-case "re$uie a.u"e "o" "impul in .edere urma"oarele: 5aca exista similaritati intre o serie de actori atunci s'ar putea crea o clasa de $aza a acelor actori din care sa deri"e acestia folosind relatia de generalizare. 5aca exista similaritati intre o serie de use'cases care cum ar fi un flux comun de acti"itati (e"entual folosit in mod repetat) atunci s'ar putea crea un nou use'case care sa fie folosita de catre primele folosind relatia de incluziune (KKusesLL). 5aca exista un caz apecial al unui use'case atunci se "a folosi o relatie de tip KKextendsLL. Ru tre$uie sa existe "re'un actor fara nici o asociere 5aca exista o functionalitate cunoscuta care nu este a$ordata de "re'un use'case atunci se "a crea un nou use'case pt respecti"e functionalitate.

Class Diagram
3lass diagrams sunt pro$a$il cele mai importante diagrame 2-L. #n modelarea orientata pe o$iecte clasele o$iectele si relatiile dintre ele sunt principalele elemente pentru modelare. 3and se foloseste programarea orientata pe o$iecte pentru realizarea sistemelor software clasele si relatiile de"in c*iar codul insusi. 7 class diagram arata cum diferitele entitati (persoane lucruri si date) sunt relationate intre ele scopul ei principal fiind acela de a descrie structura statica a sistemului care este modelat. &punem ca diagramele claselor sunt statice deoarece nu descriu ceea ce se intampla in momentul in care clasele relationate interactioneaza. 3lasele sunt cele mai importante concepte in programarea orientata pe o$iecte si s'ar putea spune si in lim$a.ul 2-L. 1rincipalele proprietati ale unei clase sunt: numele stereotipul si "izi$ilitatea (pu$lic protected sau pri"ate). -odeland structura statica a claselor o class'diagram prezinta structura interna a fiecarei clase (atri$ute operatii) precum si cel mai important aspect si anume relatiile pe care fiecare dintre clase le are cu celelalte clase (asocieri generalizari etc). 1entru a crea o class diagram clasele tre$uie sa fie identificate si descrise. #dentificarea claselor o putem face raspunzand la urmatoarele intre$ari: +"em un tip de informatie care tre$uie depozitat sau analizatM +"em sisteme externe inglo$ate in acti"itatea sistemului modelatM ?xista dispoziti"e pe care sistemul tre$uie sa le m/nuiascaM ?xista $i$lioteci sau componente din alte proiecte care "or fi folosite in sistemM +ctorii folositi (din use'cases) au un rol in sistem a.i. "or tre$ui implementati ca fiind claseM 5aca se raspunde cu da la una dintre aceste intre$ari atunci "om a"ea un posi$il candidat de a fi implementat drept clasa. 3lasele pot fi impartite in clase: acti"e: cele care initiaza si contoleaza fluxul acti"itatii

<

 pasi"e: depoziteaza informatii si ser"esc celorlaltor clase sau clase a$stracte: nu pot fi instantiate o$iecte de tipul acestor clase (folosite pentru mostenire: o clasa care mosteneste o clasa a$stracta a"and functii a$stracte "a tre$ui neaparat sa implementeze aceste operatii NL sa le scrie codul) concrete: opusul a ceea ce se numeste clasa a$stracta #n am$ele cazuri cand exista o mostenire daca se rescrie codul unei operatii un o$iect apartinand acestei clase "a folosi noul cod al operatiei respecti"e.

0igura de mai sus demonstreaza ca o clasa are atat atri$ute cat si operatii. Rotatia 2-L pentru o clasa este un dreptung*i imparit in trei parti: numele clasei atri$utele si operatiile. 7 clasa a$stracta "a a"ea numele scrise cu caractere italice. Delatiile dintre clase "or fi reprezentate de liniile conectoare. 2nele dintre aceste tipuri de relatii sunt de.a cunoscute ele aparand si la diagramele de tip use'case.

1F

1rimul compartiment al dreptung*iului clasei si anume numele clasei este de o$icei un su$stanti" care tre$uie sa fie deri"at din domeniul pro$lemei analizate si de asemenea tre$uie sa fie cat mai putin am$iguu posi$il. 1entru un mai mare grad de a$stractizare se poate apasa H8ide all compartmentsI ceea ce "a duce la afisarea clasei su$ forma unui mic dreptung*i simplu (nu "or mai fi afisate compartimentele aferente atri$utelor si operatiilor). 3elelalte compartimente sunt cele corespunzatoare atri$utelor si operatiilor. 2n atri$ut este folosit pentru a pastra informatii care descriu si identifica o instanta specifica a clasei. 2n atri$ut are un tip care poate fi predefinit sau primiti" (integer real &tring $4te c*ar T) sau poate fi o instanta a unei clase construite tot de noi. (#n lista tipurilor ne "or aparea si clasele definite de noi deci unui atri$ut "a putea fi de un astfel de tip). 3eea ce tre$uie mentionat este faptul ca aceste tipuri primiti"e nu apartin lim$a.ului 2-L ci unui anumit lim$a. de programare setat in cadrul unealtei 3+&? folosite. 5in figura de mai sus se o$ser"a ca in cadrul diagramei se pot specifica declaratorii de acces (specifica "izi$ilitatea) si sunt cei cunoscuti si folositi in mediile de programare 771. +cestia sunt pu$lic (accepta referirea din alte clase) pri"ate (nu accepta referirea din alte clase) si protected (accepta referirea numai din clasele fiu NL protected este folosit impreuna cu o relatie de generalizare sau specializare). +sadar declaratorii de acces sunt folositi pentru specificarea modului de acces la informatiile incapsulate in clase. +m "azut ca atri$utele sunt "alori care caracterizeaza o$iectele clasei cateodata "alorile atri$utelor fiind o cale de a descrie starea o$iectului. 7peratiile cele afisate in al treilea compartiment al figurii ce reprezinta clasa sunt folosite pentru a manipula atri$utele sau pentru a performa alte actiuni. 7peratiile sunt de o$icei numite functii sau metode dar ele sunt interioare unei clase si deci "or putea fi aplicate numai o$iectelor clasei. 7 operatie are un tip returnat un nume si zero sau mai multi parametrii. #mpreuna tipul returnat numele si parametrii sunt numite signatura operatiei. &ignatura descrie tot ce este ne"oie pentru a folosi operatia. 1entru a performa o operatie o operatie este aplicata unui o$iect al clasei (este numit pe un o$iect). 7peratiile intr'o clasa descriu ce poate face o clasa ce ser"icii ofera si pot fi "azute ca fiind interfata unei clase. ?ste posi$il ca o operatie sa ai$a o "aloare de tip default pentru un parametru. +ceasta inseamna ca in cazul in care apelantul operatiei nu specifica un parametru operatia "a folosi "aloarea default pt acel parametru. 3and un o$iect (instanta al unei clase) este creat atri$utele si lin9urile ar tre$ui sa fie automat initializate. 1entru acest lucru am putea a"ea o operatie statica care sa faca acest lucru sau am putea crea un asa'zis constructor cel care "a corespunde unui constructor dintr'un anumit lim$a. de programare (3@@ Aa"a). #n 2-L un constructor este redat printr'o operatie a"and acelasi nume cu clasa care are stereotipul HcreateI. 7 operatie a"and stereotipul Hdestro4I este ec*i"alentul unui destructor din 3@@ si "a fi responsa$ila in eli$erara spatiului de memorie alocat o$iectelor dinamice. 3u"antul c*eie HleafI pentru o clasa indica faptul ca acea clasa nu este conceputa pentru a a"ea su$clase pe cand cu"antul HrootI indica faptul ca acea clasa este radacina unui ar$ore de deri"are.

11

+tat operatiile cat si atri$utele pot fi statice (afisate su$liniat) deci nu "or apartine unei instante a clasei din care pro"ine ci "or apartine c*iar clasei fiecare dintre instantele clasei a"and acces la acestea. 2n atri$ut static mai poate fi denumit si o "aria$ila a clasei putand fi accesat si fara sa existe "re'o instanta a unei clase pe cand o operatie statica este folosita cu scopuri generice cum ar fi crearea sau gasirea unui o$iect acolo unde un o$iect specific nu exista. 1rincipalele tipuri de relatii care se pot gasi intr'o class'diagram sunt: 3ela"ii de asociere: este o legatura intre doua clase (NLeste o relatie si dintre o$iectele instante ale celor doua clase). #n 2-L o asociere este o legatura o conexiune semantica intre doua clase. (U 1ri"iti codul sursa generat pentru clasele 3erc si 1unct pentru o mai $una intelegere a notiunii de asociere). 7 relatie de asociere tre$uie sa fie o linie simpla daca am$ele clase sunt constiente de existenta celeilalte sau o sageata orientata in cazul in care asocierea este cunoscuta doar de una dintre clase. +socierile au mai fost intalnite si la diagramele use'case insa intr'o class'diagram mai poate aparea un tip de asociere numita asociere recursi"a. 7 clasa poate fi conectata de ea insasi printr'o asociere ca in exemplul de mai .os:

7$ser"ati in exemplu de mai sus ca asocierea numit Hcasatorit(a) cuI are cele doua capete denumite HsotI respecti" HsotieI aceste denumiri fiind de fapt rolurile .ucate de instante ale clasei in cadrul asocierii. 3ela"iile de mos"enire O &unt niste relatii care pot aparea intre interfete sau clase insa nu si intre interfete si clase. &im$olul 2-L pentru o relatie de mostenire ar fi o linie cu un triung*i al$ in capatul dinspre superclasa. 3lasa specializata (su$clasa) mosteneste atri$utele operatiile si c*iar si asocierile clasei generale (superclasei).

1!

3ela"ii de dependen"a O reprezinta o legatura semantica intre doua elemente ale modelului unul dependent de cel pe care il "om numi independent. 7 sc*im$are in elementul independent "a afecta si elementul dependent. 3ela"ii de "ip reali5a"ion O Delatii care exista doar intre interfete si clase. +sta inseamna ca o clasa "a HmosteniI toate operatiile interfetei si $ineinteles "a putea a"ea si alte operatii proprii. /ac7ages O 2n pac9age este un mecanism de grupare folosit pentru organizarea elemntelor in grupuri de elemente a"and o legatura semantica. +sadar pac9age'urile sunt folosite pt structurarea modelului (un element poate fi continut doar de un singur pac9age) iar in cadrul unei class'diagram ele sunt folosite pt specificarea explicit a ierar*iilor. +sa cum clasele se pot plasa direct intr'un model asa se pot situa si in interiorul pac9age'urilor exprimand astfel interdependentele existente intre anumite pac9age'uri. 2n pac9age prezinta similaritati cu o agregare in sensul ca pac9age'ul isi detine elementele( daca insa importa elemente din alte pac9age'uri "om spune ca a"em de'a face cu o s*ared aggregation. #mportarea dintr'un pac9age este "azuta ca o dependenta a"and stereotipul KKimportsLL. 6n"erfe"e O sunt un fel de clase restrictionate in a contine doar operatii nu si atri$ute. 5in punct de "edere grafic o interfata este reprezentata printr'un dreptung*i cu doua compartimente (nume@operatii) a"and stereotipul KKinterfaceLL. 7peratiile sunt a$stracte si nu au nici o implementare in cadrul interfetelor. 5espre clasele care au o legatura cu o interfata "om spune ca implementeaza acea interfeta si ele "or fi ne"oite sa implementeze aceste operatii (metode) respecti" sa scrie codul acestora.

13

!c"ion diagram &copul diagramele de acti"itate este acela de a modela actiunile (munca @ acti"itati) implementate in operatii in special in cele dintre doua sau mai multe clase si de a prezenta rezulatele acestor actiuni. #n proiectele in care sunt prezente use'cases o diagrama de acti"itate poate modela un use'case anume la un grad de detaliere mai mare insa aceste diagrame pot exista si independent de use'cases si folosite pentru: reprezentarea actiunilor executate odata cu o operatie (instanta implementarii unei operatii) reprezentarea acti"itatii interne a unui o$iect a arata cum un set de actiuni pot fi execuate si cum "or afecta o$iectele din .ur a arata cum functioneaza anumite sisteme referirea facandu'se la actori (muncitori) organizare cursul acti"itatiiT ?xemplu: modelarea unor functionalitati ale unui sistem sau su$sistem. 7 diagrama de acti"itate se concentreaza asupra succesiunii in executie a actiunilor si asupra conditiilor (trigger sau guard) care declanseaza aceste actiuni. 5e asemenea o diagrama de acti"itate se concentreaza asupra actiunilor interne ale acti"itatilor si nu asupra actiunilor care apeleaza acti"itatea in plin progres sau asupra triggerelor ce declanseaza acti"itatea. 7 actiune este facuta pentru a produce un rezultat. #mplementarea unei operatii poate poate fi descrisa ca un set de actiuni a"and legatura actiuni care mai tarziu "or f transformate in cod. Rotatiile diagramelor de acti"itate sunt foart asemanatoare cu a celor de stari (statec*art diagram) de fapt conform specificatiilor 2-L o diagrama de acti"itate poate fi considerata o "arianta a unei diagrme de stari. +sadar la fel ca si o diagrama de stari diagramele de acti"itate incep cu un #nitial &tate care este conectat de prima stare printr'o tranzitie iar acti"itatile care termina modelul sunt conectate de un 0inal&tate la fel ca la diagramele statec*art. ?xemplu:

#n diagramele de acti"itate trecerea de la o stare la alta (stare N action'state) se face atunci cand actiunea starii respecti"e este terminata ( NL nu este necesara specificarea unui e"eniment ca in diagramele statec*art ). &pecificatiile 2-L permit existenta unei singure stari initiala care sa ai$a doar o singura tranzitie care conecteaza starea initiala de o alta stare. ?ste posi$il insa ca o acti"it4 diagram sa ai$a mai multe stari finale care sa reprezinte terminarea unei ramuri logice cu alte cu"inte o acti"itate poate sa se termine in diferite maniere. 1entru definirea unor astfel de ramuri logice se folosesc punctele de decizie. +cestea "or a"ea atasate niste guard'uri adica o conditie care la un moment dat poate lua "aloarea +de"arat sau 0als. #n functie de aceasta "aloare de ade"ar acti"itatea "a urma un curs sau altul. ;uardurile "or fi atasate de tranzitiile care pleaca din punctul de decizie si in mod normal la un moment dat numai unul dintre aceste guarduri tre$uie sa ai$a "aloarea de ade"ar 6rue. 6ranzitiile dintre stari au aceeasi sintaxa ca la statec*art exceptie facand e"enimentele. ?"enimentele pot fi atasate doar de tranzitiile care leaga punctul de start de primul action'state. ?le pot a"ea atasate conditii guard sau actiuni insa atunci cand acestea lipsesc (de cele mai multe ori) tranzitia "a a"ea loc atunci cand toate acti"itatile din action'state se "or termina.

14

3and tranzitiile sunt prote.ate de conditii guard tranzitia se "a face numai atunci cand conditia "a lua "aloarea de ade"ar 6rue. 0olosind un 0or9 o tranzitie poate fi di"izata in doua sau mai multe tranzitii. +ceste actiuni "or fi executate concurent iar in cazul in care aceste tranzitii paralele se "or uni (printr'un Aoin) este foarte important ca ele sa'si termine actiunea inainte de unire. 1entru a arata explicit unde sunt facute actiunile (in ce o$iect) se folosesc asanumitele swimlanes. +cestea se prezinta su$ forma unor dreptung*iuri iar acti"itatile corespunzatoare unor astfel de swimlanes "or fi plasate in interiorul dreptung*iurilor. 0iecarui swimlane ii este dat un nume care este pus in partea superioara a dreptung*iului.

15

Colla$ora"ion diagram
3olla$oration diagrams descriu atat natura statica cat si natura dinamica a unui sistem. 7 cola$orare defineste rolurile care "or fi .ucate atunci cand se executa su$rutinele unui sistem. +ceste roluri "or fi .ucate de instante ale claselor aflate in directa interactiune.
Collaboration Rol e role name Class role name

role name

role name

5iagramele de cola$orare sunt o alta modalitate de reprezentare a interactiunilor si a relatiilor dintre o$iecte. &pre deose$ire de diagramele de tip seVuence ele nu se concentreaza pe succesiunea in timp a interactiunilor ci mai degra$a pe conexiunile structurale dintre o$iectele care cola$oreaza si pe rolurile pe care acestea le .oaca in cadrul unei cola$orari. 2n interes special il au in diagramele colla$oration mesa.ele sc*im$ate de o$iecte precum si scopul pentru care sunt sc*im$ate aceste mesa.e. La fel ca si o diagrama de sec"enta o diagrama de cola$orare poate fi folosita sa ilustreze executia unei operatii a unui use'cases sau pur si simplu sa ilustreze un scenariu de interactiune intr'un sistem. 7 diagrama de cola$orare descrie un set de o$iecte impreuna cu relatiile dintre ele precum si interactiunile dintre acestea adica felul in care respecti"ele o$iecte coopereaza pentru a defini functionalitatea unui sistem sau su$sistem. ?ste foarte utila modelarea interactiunilor pentru un sistem in timp real pentru ca astfel se poate ilustra atat structura statica cat si cea dinamica a o$iectelor care se afla in interactiune. 7 singura diagrama de cola$orare poate reprezenta mai mult de un fir de executie precum si o transmitere simultana a mai multor mesa.e. 5iagramele de cola$orare arata o$iecte si legaturile dintre acestea precum si felul in care mesa.ele sunt trimise intre o$iectele conectate (prin legaturi). 7$iectele sunt desenate la fel ca si clasele (in forma restransa) insa numele o$iectului este su$liniat (numele sim$olului o$iect). Legaturile arata foarte mult cu asocierile insa le lipseste multiplicitatea. 7 diagrama de cola$orare incepe cu un mesa. care initiaza intreaga interactiune sau cola$orare. -esa.ele (stimulii) sunt folositi pentru a descrie interactiunea dintre o$iecte si lor li se pot atasa cate o etic*eta'mesa. care defineste printre alte lucruri si un numar de sec"enta pentru mesa.ul respecti". -esa.ul acesta "a fi de cele mai multe ori un apel de procedura (operatie) ca in figura de mai .os.

16

2n actor trimite un mesa. pentru printare catre un computer. 3omputerul trimite un mesa. de printare ser"erului care la randul lui "a trimite un mesa. de imprimare catre imprimanta (daca aceasta este li$era). -esa.ele sunt numerotate astfel: ' primul mesa. cel care porneste o sec"enta intreaga de mesa.e "a fi numerotat cu 1 ' mesa.ul 1.1 este primul mesa. care decurge din rezol"area primului mesa. ' mesa.ul1.! este urmatorul ' mesa.ele trimise in paralel adica cele concurente pot fi descrise folosind litere in cadrul expresiei numerice care exprima succesiunea mesa.elor. 5e exemplu !.1.a si !.1.$ "or fi folosite pentru doua mesa.e care "or fi trimise in paralel. 2n Lin9 este o conexiune dintre doua o$iecte care cola$oreaza. -esa.ele (stimulii) "or fi pozitionati de'a lungul acestora. Dolul .ucat de un o$iect intr'o cola$orare "a fi aratat la capetele lin9'urilor. 2nui astfel de rol i se pot atasa diferite stereotipuri cum ar fi: ' glo$al: specifica faptul ca instanta respecti"a este "azuta in intregul sistem si poate fi apelata folosind un nume cunoscut oriunde in sistem ' local: specifica faptul ca instanta respecti"a este "azuta deoarece este o "aria$ila locala intr'o operatie. ' parameter: specifica faptul ca instanta respecti"a este "azuta deoarece este un parametru a unei operatii ' association: specifica faptul ca instanta respecti"a este "azuta doar de catre o$iectele aflate in asociere ' self: specifica faptul ca instanta respecti"a este "azuta doar de catre ea insasi 7$iectelor create in timpul unei cola$orari "or a"ea constrangerea WnewX iar cele care sunt distruse in timpul cola$orarii "or a"ea constrangerea Wdestro4edX. 7$iectele care sunt si create si distruse in cadrul aceleiasi cola$orari "or a"ea constrangerea WtransientXcare este ec*i"alenta cu WnewXWdestro4edX. 7$iectele cele care .oaca rolurile din digrama de cola$orare "or fi etic*etate cu nume de clase de o$iecte sau cu am$ele. Rumele claselor sunt precedate de H:I iar fiecare mesa. din diagrama are un numar care "a indica succesiunea acestora. 1rimul mesa. "a fi numerotat cu 1 iar mesa.ele de pe acelasi ni"el (trimise in timpul aceluiasi apel) au acelasi prefix dar "or continua cu un sufix diferit in ordinea in care mesa.ele "or fi transmise. ?xista mai multe tipuri de mesa.e si anume: ' simple: arata cum controlul este pasat de la un o$iect la altul fara a se da "re'un detaliu despre comunicare( acest tip de mesa. este folosit este folosit cand nu se cunosc detalii despre comunicare sau cand aceste detalii nu sunt considerate rele"ante in diagrama la care se lucreaza( mesa.ele simple mai sunt folosite pentru a arata faptul ca controlul este dat inapoi de la o$iectul care a primit un mesa. sincron la cel care a initiat acel mesa.. ' sincrone: similare cu un apel al unei operatii( operatia care primeste mesaul isi termina toate operatiile (inclusi" transmiteea de alte mesa.e) inainte ca o$iectul care a initiat primul mesa. sa'si continue executia( aceasta reintoarcere catre primul o$iect poate fi reprezentata ca un mesa. sau poate fi considerata implicita la terminarea operatiei care se ocupa de mesa.ul transmis. ' asincrone: sunt folosite acolo unde nu exista o reintoarcere explicita in cadrul o$iectului care initiaza mesa.ul acesta continuandu'si executia dupa transmiterea mesa.ului fara sa astepte rezultatul operatiilor care se "or executa odata cu transmiterea mesa.ului( acest tip de mesa. este folosit in sistemele in timp real unde o$iectele se au o executie concurenta. 2n mesa. simplu si unul sincron pot fi com$inate pentru a arata ca la transmiterea mesa.ului returnarea controlului are loc aproape instantaneu. +dnotari cu pri"ire la timp pot fi adaugate diagramelor de cola$orare insa nu asa clar ca intr'o diagrama de tip seVuence. +ceste adnotari "or fi de fapr notite sau constrangeri atasate diferitelor elemente din diagrama.

17

5iagrama de cola$orare din figura de mai sus arata interactiunile care au loc cand un senzor al unei alarme detecteaza ce"a. +cesta trimite un semnal de alarma asincron catre 3ell 8andler. #n continuare 3ell 8andler trimite in paralel semnale (mesa.e) asincrone paralele catre toate alarmele (in acest caz un telefon si un alarma sonora) si un semnal de tot asincron catre &4stem 8andler. &4stem 8andler folosind &uper"iser "a trimite un stimul pentru declansarea alarmei interne iar apoi "a scrie e"enimentul intr'un fisier log. 7 diagrama de cola$orare furnizeaza o poza $una a am$elor structuri a o$iectelor implicate si interdependenta lor. 2n o$iect acti" se executa deodata cu t*read'ul sau de control. 2n actor de la un anumit eta. apasa un $uton. ?le"ator control creeaza o noua sarcina pt lift pe care o introduce in coada liftului. 7$iectul ele"ator este acti" ruleaza concurent si isi extrage noile sarcini din coada sa.

1=

&e'uence Diagram
7 diagrama de sec"enta este o diagrama ce descrie structura dinamica a unui sistem aratand interactiunile dintre instantele unor clase (o$iecte) in momentul rularii programului (functionarii sistemului) oferind o *arta a modului de transmitere a mesa.elor intre o$iecte in timp (NL se modeleaza operatiile care "or tre$ui incluse in clasele sistemului precum si e"enimentele suportate de clase). 0rec"ent acest tip de diagrame "or fi situate su$ 2se'3ases sau su$ diferite componente pentru a ilustra un scenariu (nu un algoritm) sau niste succesiuni de pasi care sunt parcursi la aparitia unui e"eniment. 7 astfel de diagrama "a arata ce o$iect initiaza acti"itatea intr'un sistem ce procese si sc*im$ari "or a"ea loc intern in cadrul sistemului si ce date de iesire "or fi generate in urma interactiunilor dintre o$iecte. +sadar o diagrama de sec"enta "a reprezenta un scenariu 2se 3ase (sau o parte a unui scenariu 2se 3ase) sau un curs al e"enimentelor concentrandu'se pe succesiunea in timp a interactiunilor din timpul executiei care este determinata prin citirea diagramei de sus in .os. 7 diagrama de sec"enta are doua dimensiuni: ' dimensiunea "erticala: arata succesiunea mesa.elorPapelurilor ordonate in functie de momentul in care apar (functie de timp) ' dimensiunea orizontala: arata o$iectele catre care sunt trimise mesa.ele (7$iectele implicate sunt listate de la stanga la dreapta dupa momentul in care sunt implicate in sec"enta de mesa.e) 7$iectele care "or participa la interactiuni "or a"ea urmatoarea sintaxa: #nstanta3lasa : Rume3lasa (ex. m4Deport;enerator : Deport;enerator). 3a notatie 2-L o diagrama de sec"enta "a consta dintr'un set de o$iecte fiecare a"and o linie "erticala punctata care reprezinta "iata o$iectului respecti" (linia "ietii). +ceasta linie a "ietii reprezinta timpul cat o$iectul respecti" continua sa existe si a.uta la reprezentarea mesa.elor (atat cele primite cat si cele transmise) si acti"arii o$iectelor. -esa.ele (stimulii) sunt desenate ca fiind sageti trasate de la un o$iect la altul. 5aca o instanta a unei clase trimite un mesa. (stimul) unei alte instante se "a desena o sageata (desc*isa) orientata spre instanta care "a primi mesa.ul. Rumele mesa.ului (stimulului) precum si a actiunii care se "a executa "or fi plasate deasupra acestei sageti. +ctiunea executata este de cele mai multe ori o operatie implementata in cadrul clasei o$iectului care primeste mesa.ul. 5aca aceasta operatie returneaza o "aloare care este importanta in desfasurarea executiei programului se poate desena o sageata punctata orientata spre o$iectul apelant (numita return stimulus in 1oseidon). ?lementele uneidiagrame de sec"enta: Y 7$.ects O ?lementele responsa$ile cu transmiterea si receptionarea mesa.elor Y 3all stimuli O Deprezinta un mesa. sincron (care este "azut ca un apel de functie) Y &end stimuli O Deprezinta un mesa. asincron (care este "azut ca un semnal)3el care transmite mesa.ul nu asteapta un raspuns de la cel care primeste mesa.ul. Y Deturn stimuli O Deprezinta ceea ce se returneaza in urma unui call stimulus. Y 3reate stimuli O 0olosit pentru a crea un nou o$iect la un anumit dat in cadrul sec"entei de interactiuni. Y 5estro4 stimuli ' 0olosit pentru a distruge un o$iect la un anumit dat in cadrul sec"entei de interactiuni. Linia "ietii acelui o$iect care "a fi distrus se "a termina printr'o cruce in momentul trimiterii stimulului.

1<

Componen" and Deplo)men" Diagrams

-a.oritatea uneltelor 3ase existente permit crearea unei astfel de diagrame su$ denumirea de deplo4ment diagram +rgo2-L nici 1oseidon nefacand exceptie de la aceasta. #n 1oseidon se pot edita c*iar si 7$.ect 5iagrams in cadrul sectiunii diagramei 5eplo4ment deoarece s'au introdus si notatiile pentru 7$.ect in tool$ar'ul aferent. 7 astfel de diagrama ofera o "edere din punct de "edere fizic asupra sistemului. &copul ei este de a arata dependentele pe care software'ul dez"oltat le are cu alte componente software din cadrul sistemului (?x: $i$lioteci de functii). 7 diagrama de componenta poate reprezenta sistemul la un ni"el superior (*ig*'le"el) ilustrand numai principalele componente la un ni"el de detaliere foarte mic sau la un ni"el inferior (low'le"el) unde "or fi ilustrate componentele pana la ni"elul pac9age'urilor. 5iagramele de componenta sunt foarte folositoare in cazul in care se lucreaza la un proiect cu un numar relati" mare de ec*ipe de dez"oltare. ?le a.uta la modelarea si apoi identificarea componentelor software si a interfetelor acestora. 7 data ce interfetele au fost definite si acceptate de ec*ipe este mult mai usor de organizat efortul de dez"oltare al su$ec*ipelor. 1rincipalele elemente ale unei 3omponent 5iagram: Y 9odes and 6ns"ances of 9odes O nodurile reprezinta elementele *ardware ale sistemului distri$uit (acestea sunt folosite numai in cazul diagramelor de tip deplo4ment) Y Componen"s and 6ns"ances of Componen"s O componentele tin locul elementelor software care sunt repartizate in *ardware'ul sistemului. Y Lin7s O sunt folosite pentru conectarea o$iectelor sau instantelor de noduri. Y Dependencies O acestea exista intre diferite componente si pot fi specificate utilizand stereotipi (predefinite sau nu). Y !ssocia"ions ' sunt folosite pentru a ilustra relatiile de comunicare dintre noduri. La fel ca dependentele si asocierile pot fi specificate folosind stereotipi. Y ,$-ec"s0 Classes0 6n"erfaces ' componentele si nodurile pot include o$iecte clase sau interfete. 5upa un timp clusterele de clase cu interactiune puternica "or forma un fel de unit si "or iesi in relief in cadrul ar*itecturii. +ceste clustere "or putea fi reprezentate in lim$a.ul 2-L su$ forma unor componente. 3omponentele sunt de fapt fisierele existente in mediul de dez"oltare folosit pentru constructia unui s4stem. ?le sunt $locurile care alcatuiesc sistemul distri$uit pe diferite alte elemente *ardware (aceste elemente *ardware pot fi si computere diferite). 5e fapt ele sunt artefacte de ni"el inalt cum ar fi .a"a $eans dll'uri ocxZs'uri si alte produse software de multe ori compuse din alte elemente mai simple cum ar fi clase si functii din $i$lioteci. 3omponentele mai pot fi "azute si ca implementarea in ar*itectura fizica a unui sistem a conceptelor si functionalitatilor definite in ar*itectura logica (clase o$iecte diferite relatii si cola$orari). 0iecare componenta "a oferi ser"icii altor componente (numite clienti) aceste ser"icii numite contracte facandu'se de o$icei prin intermediul interfetelor. ?xemple de componente: +cti"eE 3ontrol: set de te*noloogii -icrosoft care ofera continut interacti" pt [orld [ide [e$ (efecte multimedia o$iecte interacti"e) 5ll (d4namic lin9 li$rar4) Aa"a:ean (suport pt ser"ere de aplicatii) 1agini [e$

!F

7 componenta software poate fi: source component (3ompile'6ime 3omponents): un fisier continand cod sursa in care sunt implementate una sau mai multe clase( o astfel de componenta are un inteles la momentul compilarii (compile time) celelate tipuri de componente fiind generate de componente de acest tip 1entru 3ompile'6ime 3omponents se pot folosi urmatoarele stereotipuri: ' KKfileLL: fisier continand cod sursa ' KKpageLL: o reprezentare a unei pagini we$ ' KKdocumentLL: reprezentate a unui fisier continand documentatie nu cod

$inar4 component (Lin9'6ime 3omponent): cod o$iect care este rezultatul compilarii a unuia sau mai multor componente sursa( o astfel de componenta poate fi un fisier cu cod o$iect (o$.) un fisier static sau dinamic de functii (li$rar4 files) care are un inteles la lin9'time sau in cazul unei li$rarii dinamice la run'time (o astfel de $i$lioteca este incarcata de o componenta executa$ila doar in momentul rularii) 1entru Lin9'6ime 3omponents se pot folosi urmatoarele stereotipuri: ' KKprocessLL: simplu proces ' KKt*readLL: fir de executie

executa$le component (Dun'6ime 3omponent): un fisier executa$il (exe) care este rezultatul procesului de lin9ing al tuturor componentelor $inare (statrice la lin9'time si dinamice la run' time) sau cateodata direct din 3ompile'6ime 3omponents (ex. Aa"a)( o astfel de componenta reprezinta unitatea executa$ila care "a fi rulata de catre processor (computer) 1entru Dun'6ime 3omponents se pot folosi urmatoarele stereotipuri: ' KKapplicationLL: reprezinta un fisier executa$il ' KKta$leLL: o reprezentare a unui ta$el dintr'o $aza de date folosit drept componenta la run'time

!1

&a presupunem ca dorim sa construim un software pentru muzica de pe 35'uri (un pla4er) a carui interfata simpla ar include doar $utoanele o$isnuite . +tunci am a"ea urmatoarea diagrama de componenta:

#n 2-L o componenta este ilustrata su$ forma unui dreptung*i uneori a"and o elipsa plus inca doua mici dreptung*iuri in stanga. 3omponentele sunt niste tipuri insa numai componentele executa$ile pot a"ea instante (atunci cand programul pe care'l reprezinta este executat de compilator ). 1rincipiile designului de componente: nu tre$uie sa existe cicluri de forma + : 3 + unde sageata reprezinta o relatie de dependenta daca o clasa localizata intr'o anumita componenta este sc*im$ata atunci acest lucru nu tre$uie sa afecteze clase din afara componentei respecti"e daca o clasa dintr'o componenta tre$uie sa fie reutilizata "a tre$ui sa fie reutilizate toate clasele incluse in acea componenta (niciodata nu se "a reutiliza numai o parte a unui element software) a$stractiile nu tre$uie sa depinda de detalii ci detaliile "or tre$ui sa depinda de a$stractii elementele software "or tre$ui sa fie desc*ise pentru extindere dar inc*ise pentru modificare daca + depinde de : atunci : ar tre$ui sa fie mai sta$ila (mai putin pro$a$il de a suferi modificari) componenta tre$uie sa fie suficient de a$stracta pentru ca sa poata fi extinsa fara a'# fi afectata sta$ilitatea. #n timp construind astfel de componente in cadrul unei ar*itecturi se poate a.unge la o structura ar*itecturala reutiliza$ila care "a putea fi folosita cu succes in cadrul altor si altor sisteme. 7 component diagram arata felul cum sunt organizate componentele software (source $inar4 executa$le) relatiile dintre si dependentele existente intre acestea felul in care comunica etc. 7 astfel de diagrama este folosita de o$icei pentru prezentari de mar9eting sau rezumate a ar*itecturii unui sistem. 7 sageata punctata intre doua componente inseamna ca o componenta are ne"oie de o alta pentru a fi definite complet. 7 astfel de dependenta intre o source component + si o source component : inseamna ca o sc*im$are in : necesita o recompilare si a lui +. 5aca componentele intre care exista o dependenta sunt executa$ile atunci citind o astfel de diagrama "om putea identifica de ce li$rarii dinamice are ne"oie un program pentru a putea rula. 7 componenta poate sa implementeze una sau mai multe interfete care sa poata fi "azute de alte componente (NLpu$lica comportamentul componentei respecti"e). +ceste interfete pot fi definite la ni"el cod (ex: interfete Aa"a) sau $inar4 folosite la run'time (ex. 7L?).

!!

Legatura unei componente cu o anumita interfata poate fi reprezentata in doua moduri dupa felul acestei legaturi. 3omponenta ofera de o$icei o interfata si in acest caz se "a folosi notatia tip loll4pop. #ncepand cu 2-L! a fost introdusa sim$olul de soc9et pentru a indica faptul ca este ne"oie de implementarea unei interfete. +cest sim$ol poate fi considerat un stereotip "izual pentru o dependenta. (in locul lui poate fi folosita o dependenta o$isnuita cu stereotipul KKreVuireLL). 2n port (notatia 2-L N patrat mic) "a fi o caracteristica a unei componente ce specifica un punct de interactiune a componentei cu mediul extern. +ceste porturi care pot a"ea si un nume "or putea suporta o comunicatie unidirectionala sau $idirectionala dupa caz. Ru este ne"oie sa fie folosite toate interfetele unei componente.

0igura de mai .os ilustraza patru componente: Deporting 6ool :ill$oard &er"ice &er"let !.! +1# and A5:3 +1#. ?xistenta sagetilor care pleaca de la componenta Deporting 6ool catre componentele :ill$oard &er"ice &er"let !.! +1# and A5:3 +1# inseamna ca Deporting 6ool este dependent de aceste trei componente.

7 component diagram "a arata o componenta numai su$ forma unui tip deci daca a"em ne"oie de reprezentarea unei instante a unei componente "om tre$ui sa folosim o deplo4ment diagram. , deplo4ment diagram sa o networ9 diagrams cum i se mai spune descrie felul cum componentele sunt repartizate pe diferitele computere existente in cadrul unui sistem. Rotatiile dintr'o deplo4ment diagram includ elementele notationale folosite intr'o component diagram a"and insa si cate"a adaugari cum ar fi conceptul de nod care reprezinta de fapt o masina (reala sau "irtuala). &copul unei astfel de diagrame este de a ilustra unde "or rula (dpd" fizic) diferitele componente si cum "or comunica una cu alta asadar s'ar putea spune ca o deplo4ment diagram modeleaza sistemul la run'time. 3el mai simplu exemplu de deplo4ment diagram ar fi diagrama care descrie un 13:

!3

5iagrama de tip deplo4ment din figura de mai sus arata faptul ca userul acceseaza Deporting 6ool folosind un $rowser care ruleaza pe o masina locala si se conecteaza la Deporting 6ool prin intranetul companiei folosind protocolul 8661. +ceasta ruleaza (dpd" fizic) pe ser"erul de aplicatii. 5iagrama arata componenta Deporting 6ool desenata inauntul componentei #:[e$&p*ere care la randul ei este desenata inauntrul nodului care reprezinta ser"erul de aplicatii. Deporting 6ool se conecteaza la $aza sa de date folosind lim$a.ul Aa"a si interfata #:- A5:3 +1# care apoi comunica cu $aza de date Deporting aflata pe ser"erul -4&\L &er"er folosind interogari &\L. 3omponenta Deport 6ool comunica folosind &7+1 o"er 8661& cu :ill$oard &er"ice.

!4

:i$liografie:

1) !) 3) 4) 5)

*ttp:PPwww.ici.roPDD#+Pria!FF4]3PartF=.*tm *ttp:PPwww.sparxs4stems.com.auPuml'tutorial.*tml *ttp:PPwww.uml.orgP *ttp:PPwww."isual'paradigm.comP *ttp:PPinf.uc".roP^giurcaPcoursesP3:31F5PresourcesP#ntroducereG!Fin G!F2-L.pdf 6) *ttp:PPfuninf.cs.uni$uc.roP^g*eorg*ePcursPmet5ez"&oftPlecPlF5four.pdf 7) *ttp:PPcs.u$$clu..roP^"cio$anP#nformaticaP+nul3P&#11P?sitPcursP-odelare G!F77G!F2-LG!F;D+11L?.doc =) *ttp:PPt*or.info.uaic.roP^adrianaaPumlP <) *ttp:PPwww.tec*it.roPtutorial]uml]1.p*p 1F) *ttp:PPwww.tec*it.roPtutorial]uml]!.p*p 11) *ttp:PPwww.tec*it.roPtutorial]uml]3.p*p

!5