introducere in uml

Inginerie Software Candea Radu

Introducere in UML

Autor: Radu Candea


Laborator 1

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 efectiva a codului) si testarea.

In cadrul lucrului la un proiect software sunt implicate mai multe persone, fiecare are atribuţii complementare celorlalţi. Se pot distinge mai multe specialitati:

utilizatori - exploatatorul softului;şefi de proiect - totdeauna trebuie să existe cineva cu această funcţie;

analişti de sistem - execută modelul informatic al aplicaţiei;proiectanţi de sistem - execută arhitectura programului aplicaţiei; 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 de obicei devin greu de urmarit din pricina formatarii sau a lipsei de organizare a acestora sau chiar a omiterii anumitor detalii despre o anumita componenta (modul).

In cadrul fazei de proiectare se construieste de obicei un modul al proiectului la care se lucreaza. Modelarea este o parte esentiala a unui proiect software, el jucând un rol analog cu proiectul architectural al unei cladiri de mari dimensiuni. Folosind un model cei responsabili pentru succesul sau esecul unui proiect se pot asigura inca dinainte de inceperea scrierii codului ca :

functionalitatea proiectului va fi corecta si completa toate necesitatile utilizatorului final vor fi satisfacute designul programului va satisface cerintele de scalabilitate, robustete, extendabilitate etc.

In cadrul operatiunii de modelare se pleaca de la premisa ca sistemele software sunt complexe, de aceea avem nevoie de o multitudine de viziuni simple ale acestora asfel incat in final 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, IBM Corporation, 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 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. Chiar daca UML nu poate 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 si complexe.

Unul din principalele scopuri ale dezvoltatorilor limbajului UML a fost acela de a crea un set de notatii semantice care sa se adreseze tuturor tipurilor de proiecte arhitecturale complexe indiferent de domeniu (industrial, software, marketing, constructii etc.).

UML 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 limbaj de programare, scheme ale 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 construirea modelelor software.

Exista o bogata colectie de elemente notationale grafice suportate de UML. Exista o serie de elemente care descriu clase, componente, noduri, activititati, work flow, obiecte, stari dar exista 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 ingineriei software ajutand la construirea de modele rigurase, usor de urmarit si intretinut, care sa suporte intregul 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 abstractizare atentia se concentreaza asupra detaliilor semnificante ignorandu-le pe celelalte. Aceasta este cauza pentru care:

fiecare sistem complex este abordat printr-un set de vederi diferite ale unui model. (o singura vedere nu este suficienta)

fiecare model poate fi reprezentat cu un grad diferit de fidelitate cele mai bune modele sunt cele inspirate din realitate

Este necesara constructia unui model pentru sistemele complexe deoarece mintea umana nu poate acoperi toate detaliile unui astfel de sistem. Cu cat complexitatea unui sistem creste cu atat creste si importanta folosirii unei bune tehnici de modelare si implicit a unui limbaj riguros de modelare cum este UML.

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 care ruleaza pe orice combinatie de hardware, sistem de operare sau tip de retea. Flexibilitatea lui permite modelarea aplicatiilor distribuite ce folosesc orice tip de middleware de pe piata, iar datorita faptului ca obiectele si clasele sunt definite drept concepte fundamentale un model construit in UML va putea fi relativ usor de implementat intr-o serie de limbaje de tip OOP (C++, 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 pt 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. Printre aceste standarde folosite se afla: in primul rand UML-ul, apoi XML Metadata Interchange (XMI), Scalable Vector Graphics (SVG), Object Constraint Language (OCL).


implementeaza toate specificatiile limbajului UML 1.3., fiind singura unealta care implementeaza meta-modelul UML exact asa cum a fost specificat

este o aplicatie 100% Java deci se bucura de tote calitatile unui produs Java este open-source (in plina dezvoltare)

In plus ArgoUml a fost inspirat si a tinut cont de cele trei teorii din psihologia cognitiva: reflection-in-action: designerii unor sisteme complexe nu concep un design in totalitatea

sa. 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 paginii albe” este un efect similar)

design oportunistic: descompunerea ierarhica este o strategie uzuala in designul sistemelor 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 un moment dat

generare si explorare: in prima faza sunt generate noi idei care mai apoi, in faza a doua vor fi explorate iar implicatiile lor vor fi evaluate

In figura de mai jos sunt prezentate toate diagramele precizate in specificatiile UML:

Diagramele UML Class diagrams: descriu clasele, package-urile, proprietatile lor si diferitele relatii care

pot aparea intre acestea. Object diagrams: descriu un anumit scenariu, in loc de clase, ca la class diagrams vor

aparea obiecte, instante ale acestor clase. Use-case diagrams: descriu use cases, actorii implicati (cei care interactioneaza cu

sistemul), pus diferitele relatii existente. Sequence diagrams and Collaboration diagrams: descriu secventa de mesaje

schimbate 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 diferitele

computere.


Laborator 2

ArgoUML - unealta de modelare

Suprafata de lucru a lui ArgoUML este separata in cinci parti. In partea de sus se afla meniul principal precum si o bara cu unelte care permite acesul la principalele functionalitati ale ArgoUML. Sub acestea se afla patru subferestre. Cea mai mare dintre ele (dreapta-sus) este numita subfereastra diagramelor (sau Edit Pane Toolbar) si este locul in care se vor edita in mod grafic si in care vor fi afisate diferitele diagrame. Deasupra ei se afla o alta bara de unelte numita EditPaneToolbar. In stanga sus se afla subfereastra pentru navigare (navigation pane) sau Explorer-ul de unde se poate naviga prin modelul curent. Aceasta subfereastra listeaza toate clasele, interfetele si tipurile de date ale modelului sub forma unui arbore (tree). Cele doua subferestre de jos sunt subfereastra To Do si subfereastra detaliilor. Subfereastra To DO reaminteste designerilor ceea ce acestia mai trebuie sa faca. Itemii din aceasta subfereastra pot reprezenta si note ale designerului insusi, dar cei mai multe sunt generate de asanumitii design critics. Ce este un critic? Un critic este un proces din cadrul ArgoUML care furnizeaza sugestii despre cum ar putea fi imbunatatit modelul designului la care se lucreaza. Un critic poate fi considerat “un program ce critica solutiile generate de om” (Miller in Attending).Aceste sugestii sunt bazate pe cele trei teorii cognitive despre care s-a discutat in primul laborator: reflection-in-action, design oportunistic, generare si explorare. Criticii analizeaza in mod continuu designul in lucru cautand chestiuni incomplete sau problematice. Cand o potentiala problema este gasita este generat un item “to do” care est adaugat in lista din subfereastra ToDo. Cand designerul va rezolva problema identificata, itemul corespondent acelei probleme va disparea din lista. Pentru o buna gestionare a listei itemilor generati de diferiti critici acestia pot fi grupati dupa prioritate, tipul de decizie suportat, tipul elementului de design care pricinuieste acel item s.a.m.d. Subfereastra detaliilor din ArgoUML permite editarea elementului sau itemului “to do” selectat. Aceasta subfereastra contine dupa cum se vede si in imagine mai multe taburi si anume:


Tabul ToDo Item arata descrierea itemului selectat in subfereastra ToDo. In subfereastra diagramelor elementul “cu probleme” va fi marcat cu rosu. Descrierea itemului va consta din trei paragrafe dupa cum urmeaza: 1. descrierea problemei 2. se spune de ce este importanta aceea problema pt designer 3. se enumera pasii care trebuie parcursi pentru rezolvarea acelei probleme (uneori pasii sunt parcursi cu ajutorul unui Wizard care nu sunt modali, deci se pot folosi alte unelte in timpul folosirii unui Wizard)Exista si o serie de iconite care permit inserarea unui item personal (notita de aducere aminte), destituirea itemului curent, trimiterea unui e-mail catre autorul criticului ce produce itemul sau se poate dezactiva criticul respectiv pentru 10 minute prin selectarea iconitei “Snooze”. Tabul Properties arata proprietatile elementului de design selectat. Continutul acestui tab este definit pentru orice element si variaza in functie de tipul de element selectat. (Selectia se poate face atat in subfereastra pentru navigare cat si in subfereastra diagramelor). Aceasta fereastra poate contine si diferite butoane specifice deasemenea fiecarui tip de element. Tabul Documentation permite introducerea documentatiei pentru elementul selectat indiferent de natura lui. Exista mai multe sectiuni pentru introducerea de date cu privire la autor, versiune, referiri s.a. Tabul Style permite editarea proprietatilor vizuale a elementului de design selectat. Continutul acestui tab poate varia putin functie de tipul elementului selectat. Principalele astfel de proprietati vizuale ar fi: culoarea, pozitionarea, umbra etc. Tabul Source permite un preview asupra codului sursa care va fi generat pentru elementul de design selectat. Limbajul acestui cod sursa poatefi selectat cu ajutorul unui combo-box. O instalare standard a ArgoUML va include limbajele UML si Java, dar cu ajutorul unor plug-ins se poate genera cod sursa si in limbajele C++, PHP si C# si speram altele in viitorul apropiat. Tot in versiunile viitoare, ArgoUML va permite editarea codului direct in acest tab, iar modelul UML sa fie updatat in consecinta in mod automat. Tabul Constraints permite intrarea si vizualizarea constrangerilor de tip OCL (Object Constraint Language) pentru elementul curent. OCL este un limbaj simplu orientat pe predicate logice care permite adaugarea de mai mult inteles designurilor. In timpul editarilor constrangerilor tabul Constraints se schimba intr-un editor care ofera multe functii de ajutor pentru generarea de sintaxa corecta. Tabul Tagged Values permite pentru obiectul curent introducerea unor perechi de tipul cheie-valoare cu rolul de indicatii care vor fi memorate cu elementul de design, dar care insa nu sunt interpretate de sistem. Tabul Checklist contine o lista de intrebari cu raspuns DA sau NU care ajuta designerul sa realizeze daca elementul selectat a fost proiectat bine sau nu. De fiecare data cand ArgoUML este pornit sau cand se selecteaza pentru un nou proiect, se va deschide un proiect continand un model numit untitledModel. Acest model contine o diagrama de clase goala, numita diagram1 precum si o diagrama de caz goala numita diagram1.Modelul si cele doua diagrame goale pot fi vazute in explorer, care este principala unealta de navigare prin model. In versiunea curenta, ArgoUML (0.16.1) nu poate contine activ decat un singur proiect care la randul lui suporta un singur model UML. Din moment ce un model UML poate contine un numar nelimitat de elemente si diagrame, acest lucru nu reprezinta o limitare serioasa chiar si pentru modele mari si complexe. ArgoUML salveaza informatiile continute in diagrame intr-un fisier PGML (cu extensia .pgml), informatia din model intr-un fisier XMI (cu extensia .xmi) si informatia despre proiect intr-un fisier .argo. PGML si XMI sunt open standards, iar in viitorul indepartat standardul PGML va fi inlocuit de standardul SVG (Scalable Vector Graphics creat de Adobe) cel care in viitor va putea fi generat din XMI . Toate aceste fisiere (.pgl, .xmi) sunt mai apoi arhivate intr-un fisier de


tip .zargo. Se pot extrage foarte usor fisierele .xmi si .pgml folosind o traditonala aplicatie ZIP. Alte unelete CASE (Computer Aided Software Engineering) isi creaza propriile tipuri de fisiere specifice lor => non open standard. (Rational Rose creaza modele cu extensia .ptl, iar proiectele cu .mdl).

Cu ajutorul lui ArgoUML se pot crea mai multe tipuri de diagrame UML si anume: Class Diagram: este o diagrama UML in care se reprezinta relatiile structurale dintre clasele,

interfetele si tipurile de date ale modelului la care se lucreaza.. Variante ale acestei diagrame sunt folosite pentru a arata structurile package-urilor folosite intr-un model cu tot cu relatiile dintre ele. Use Case Diagram: este o diagrama UML in care se reprezinta relatiile dintre actori si cazuri de uz (use cases).

Statechart Diagram: este o diagrama UML care reda comportarea dinamica a unui obiect (obiect activ) la toate nivelele.

Activity Diagram: o diagrama UML care reda comportarea dinamica a unui anumit sistem sau subsistem, care implica o mai mare interactiune cu user-ul.

Collaboration Diagram: o diagrama UML care descrie felul in care mesajele (procedurile) sunt schimbate intre diferite obiecte.

Deployment Diagram: o diagrama UML care arata cum un sistem se va desfasura din punct de vedere fizic intr-un anumit mediu hardware.

Sequence Diagram: analog cu Collaboration Diagram. Care reprezentare se foloseste depinde de problema luata in considerare (acest tip de diagrama se foloseste in general unde se iau in considerare subsisteme statice in timp).

Bibliotecile ArgoUML: GEF (Graph Editing Framework), inclusa in gef.rar este responsabila pentru reprezentarea si

modificarea grafica a diagramelor oferind si abilitatea miscarii elementelor in subfereastra diagramelor

NSUML (NovoSoft UML) reprezinta implementarea Java a specificatiilor limbajului UML OCL (Object Constraint Language) folosita pentru generare de cod direct din expresii OCL

Exercitiu: Sa se reprezinte printr-o diagrama use-case procesul de criticare (cel facut de un critic)


Laborator 3

Use-case Diagram

Un caz de uz (use case) este o tehnica de modelare folosita pentru a descrie functionalitatea unui sistem, deci ce ar trebui sa faca un nou sistem sau ce face deja un anumit sistem. S-ar putea spune 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 de diagrama este folosita in etapele preliminarii a procesului de design pentru a colecta cererile clientului cu privire la proiect. Asadar, constructia unui model use-case, reprezentat printr-o diagrama use-case (sau mai multe) se face de obicei dupa lungi discutii intre dezvoltatori si clienti pe baza specificatiilor asupra carora au cazut cu totii de acord.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 dintre use-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 software sa 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 acestea le 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 (schimba mesaje). Un actor reprezinta un rol nu un utilizator individual al sistemului. Asadar un actor reprezinta o clasa nu o instanta avand stereotipul <<actor>> si deci poate avea atat atribute cat si operatii (behaviours), precum si o documentatie in care sunt descrise acestea.

Sterotipii extind vocabularul UML sunt folositi la etichetarea artefactele UML pentru a indica ca acestea apartin unei anumite categorii, sau pur si simplu pentru a reda mai multe informatii 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) sau pasivi (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 functionalitate

sistemul?(actori secundari) 4. Cu ce alte sisteme va trebui sistemul nostru sa interactioneze?(sistem = alt

computer sau alte aplcatii de pe computerul pe care se dezvolta sistemul)5. 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; daca se depaseste nr 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 la urmatoarele 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 actor 2. 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 bine functinalitatea use-case-ului. La fel ca si actorii, un use-case este o clasa si nu o instanta, aceasta clasa 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 de scenariu, reprezentand de fapt un caz de folosinta a sistemului. De exemplu pt use-case-ul din figura de mai jos un scenariu ar putea fi: ”John Doe contacteaza sistemul prin telefon si semneaza o asigurare la masina lui Dacia 1100 pe care tocmai a cumparat-o”.

In figura de mai sus dreptunghiul reprezinta marginile a ceea ce inseamna sistemul.

Extension Points - Este o referinta catre o locatie dintr-un use-case unde se pot insera secvente din alte use-cases (fiecare extension point are un nume unic in cadrul use-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 (mai specific) care este perfect compatibil cu elementul parinte adaugand insa si elemente aditionale. 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” (“O masina este vehicul => generalizarea masinii este un vehicul”) si sunt folosite pt a descrie comportamentul comun al unui anumit numar de elemente. Elementul specializat (fiu) mosteneste comportamentul elementului general (superclasa sau parintele) extinzand intr-un anumit fel acest comportament. 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 in ambele directii, intr-o singura directie sau nenavigabile. O asociere intre doua elemente ar insemna (s-ar traduce) ca elementele aflate intr-o relatie de asociere “stiu una de alta”, “sunt conectate”, 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 un


stereotip. In cadrul diagramei use case-urile sunt conectate de actori cu ajutorul 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 ambele directii. O asociere poate avea si ea un nume care este de preferinta sa fie ales astfel incat sa descrie cat mai bine in ce consta respectiva asociere.

O asociere are doua capete. Multiplicitatea unui capat al asociatiei reprezinta numarul posibil 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 un singur 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 distrus automat in momentul distrugerii elementului “intreg”. In cadrul unei agregari elementul parte mai exista si dupa ce elementul “intreg este distrus”. Ca si la agregare pot fi compozitii fixe, variabile si recursive.

Dependente – Pot exista o serie de dependente semantice intre diferite element ale modelului (si intre use-cases) si are rolul de a sugera ca un element foloseste un alt element, deci depinde de acel element. Urmand sensul dependentei, o schimbare in specificatia unui element ar putea 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 de dependente: <<extend>> si <<include>>.

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

Include relationship - O relatie unidirectionala intre doua use-cases. O astfel de relatie intre use-case-urile A si B inseamna ca, inseamna ca caracteristicile lui B vor fi intotdeauna 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 a

acelor 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 de

activitati (eventual folosit in mod repetat) atunci s-ar putea crea un nou use-case care sa fie folosita de catre primele folosind relatia de incluziune (<<uses>>).

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

Nu trebuie sa existe vre-un actor fara nici o asociere Daca exista o functionalitate cunoscuta care nu este abordata de vre-un use-case atunci se

va crea un nou use-case pt respectiva functionalitate.


Exercitiu: Sa se construiasca diagrama folosirii unui bancomat (use case). Mai intai trebuie sa se identifice toti actorii implicati, iar apoi toate cazurile de uz pentru bancomat, cele principale.


Laborator 4

Class Diagram

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

O 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. Spunem ca diagramele claselor sunt statice deoarece nu descriu ceea ce se intampla in momentul in care clasele relationate interactioneaza.

Clasele sunt cele mai importante concepte in programarea orientata pe obiecte si s-ar putea 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 fiecare dintre 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 mânuiasca? Exista biblioteci sau componente din alte proiecte care vor fi folosite in sistem? Actorii folositi (din use-cases) au un rol in sistem a.i. vor trebui implementati ca fiind

clase?Daca se raspunde cu da la una dintre aceste intrebari atunci vom avea un posibil candidat

de a fi implementat drept clasa.Clasele pot fi impartite in clase:

active: cele care initiaza si contoleaza fluxul activitatii pasive: depoziteaza informatii si servesc celorlaltor clasesau clase abstracte: nu pot fi instantiate obiecte de tipul acestor clase (folosite pentru mostenire: o

clasa 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 abstracta! In 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 dntre


clase vor fi reprezentate de liniile conectoare. Unele dintre aceste tipuri de relatii sunt deja cunoscute ele aparand si la diagramele de tip use-case.

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

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 afisate compartimentele 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 trebuie mentionat este faptul ca aceste tipuri primitive nu apartin limbajului UML, ci unui anumit limbaj de 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) si protected (accepta referirea numai din clasele fiu => protected este folosit impreuna cu o relatie de 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 treilea compartiment 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 interioare unei 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 numite signatura 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 pe un 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 folosi valoarea default pt acel parametru.

Cand un obiect (instanta al unei clase) este creat, atributele si linkurile ar trebui sa fie automat initializate. Pentru acest lucru am putea avea o operatie statica care sa faca acest lucru sau am putea crea un asa-zis constructor, cel care va corespunde unui constructor dintr-un anumit limbaj 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” este echivalentul unui destructor din C++ si va fi responsabila in eliberara spatiului de memorie alocat obiectelor 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 de derivare.


Atat operatiile cat si atributele pot fi statice (afisate subliniat), deci nu vor apartine unei instante 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 si fara sa existe vre-o instanta a unei clase, pe cand o operatie statica este folosita cu scopuri generice cum ar fi crearea sau gasirea unui obiect acolo unde un obiect specific nu exista.

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 intre doua clase. (! Priviti codul sursa generat pt clasele Cerc si Punct pt o mai buna intelegere a 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 cunoscuta doar 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 fi conectata de ea insasi printr-o asociere ca in exemplul de mai jos:

Observati in exemplu de mai sus ca asocierea numit “casatorit(a) cu” are cele doua capete denumite “sot” respectiv “sotie”, aceste denumiri fiind de fapt rolurile jucate de instante ale clasei in 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 triunghi alb in capatul dinspre superclasa. Clasa specializata (subclasa) mosteneste atributele, operatiile si chiar si asocierile clasei generale (superclasei).

Relatii de dependenta – reprezinta o legatura semantica intre doua elemente ale modelului, unul dependent de cel pe care il vom numi independent. O schimbare in elementul independent 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 operatii proprii.

Packages – Un package este un mecanism de grupare folosit pentru organizarea elemntelor in grupuri de elemente avand o legatura semantica. Asadar package-urile sunt folosite pt 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 astfel interdependentele existente intre anumite package-uri. Un package prezinta similaritati cu o agregare 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 package este vazuta ca o dependenta, avand stereotipul <<imports>>.

Interfete – sunt un fel de clase restrictionate in a contine doar operatii nu si atribute. D.p.d.v grafic o interfata este reprezentata printr-un dreptunghi cu doua compartimente (nume+operatii), avand stereotipul <<interface>>. Operatiile sunt abstracte si nu au nici o implementare in cadrul interfetelor. Despre clasele care au o legatura cu o interfata vom spune ca implementeaza acea interfeta si ele vor fi nevoite sa implementeze aceste operatii (metode), respectiv sa scrie codul acestora.


Laborator 5

Modelare dinamica – Diagramele de stare

Toate sistemele au o structura statica, (descrisa de obicei de diagramele de clase) si un comportament dinamic care va putea fi descris printr-o serie de diagrame UML cum ar fi statechart (sau state in unele unelte CASE), sequence, colaboration si activity diagrams. diagramele statechart (state): descriu starile pe care un obiect le poate avea pe durata “vietii” sale si comportamentul obiectului aflat in respectivele stari impreuna cu evenimentele care au cauzat schimbarea starii diagramele sequence: descriu felul in care obiectele comunica si interactioneaza intre ele, concentrandu-se in special pe notiunea de timp ; descriu felul in care o serie de mesaje sunt schimbate intre diferite obiecte pentru a realiza o functie diagramele collaboration: descriu de asemenea felul in care interactioneaza obiectele, atentia concentrandu-se mai ales asupra notiunii de spatiu. Intr-un fel s-ar putea spune ca o astfel de diagrama contine aceeasi informatie ca o sequence-diagram insa intr-o alta forma. diagramele activity: sunt un alt mod de a descrie interactiunile care insa se cocentreaza pe descrierea muncii (activitatii) obiectelor care schimba mesaje.

!Pentru un sistem nu este obligatorie realizarea tuturor diagramelor mentionate mai sus (=> este necesara luarea unei decizii pentru alegerea diagramei potrivite functie de aspectul considerat a fi cel mai important)

Obiectele din cadrul sistemelor interactioneaza, comunica unele cu altele, prin intermediul asanumitelor mesaje. Un mesaj este de fapt doar un apel al unei functii (operatii) in care un anumit obiect invoca un altul. Cum comunica obiectele si efectele unei astfel de comunicari sunt referite ca a fi dinamica unui sistem, adica felul in care obiectele colaboreaza prin prisma comunicarii si felul cum obiectele isi schimba starea in timpul ciclului de viata al sistemului.

De obicei diagrmele statechart sunt folosite pentru a descrie comportamentul instantelor de clase, dar ele mai pot descrie si comportamentul altor entitati cum ar fi: use-cases, actori, subsisteme, operatii.

Diagramele statechart sunt folosite pentru a ajuta dezvoltatorii sa inteleaga functionalitatile complexe ale anumitor portiuni din sistemul modelat, aratand toate starile posibile ale unui obiect si tranzitiile care cauzeaza trecerile de la o stare la alta.

O diagrama de tip statechart arata comportamentul dinamic al claselor (sau al unui sistem, subsistem) ca raspuns al unor stimuli externi. Acest tip de diagrama modeleaza cursul dinamic si are multe elemente notationale similare cu o diagrama de activitate.

Orice clasa are una sau mai multe stari, dar nu fiecare clasa va trebui sa fie modelata printr-o diagrama statechart, ci doar cele care prezinta mai multe stari potentiale pe parcursul activitatii unui sistem

Principalele elemente ale unei diagrame statechart sunt:

Starile (states): reprezinta o situatie din timpul existentei unui obiect intr-un anumit moment (=>starile difera la momente diferite in timp). O stare modeleaza o situatie in timpul careia, atata timp cat o conditie este satisacuta, un anumit obiect se afla intr-o anumita situatie sau stare care poate fi o stare statica, de asteptare a unui eveniment extern sau dinamica (o activitate in progres). O stare poate fi determinata de un singur atribut al clasei, ca in exemplul de mai jos:


Exemplu: O factura este platita sau nu.

Motorul merge sau nu.

Diagrama de stare pentru o instanta a clasei Factura

Un State are urmatoarele proprietati :Name:Stereotype:Entry-Action: activitate care trebuie executata in momentul in care se intra in stateExit-Action: activitate care trebuie executata in momentul in care se iese in stateDo-Activity: activitate care trebuie executata in timpul in care obiectul se afla intr-o anumita stare (Poate fi intrerupta de un eveniment extern)Incoming: listeaza tranzitiile care aduc obiectul in starea respectivaOutgoing: listeaza tranzitiile care scot obiectul din starea respectivaInternal tranzition listeaza toate tranzitiile interne (nu scot un obiect din starea respectiva=>Entry si Exit actions nu sunt invocate).

Composite states: un state care poate contine mai multe states (stari) care de data aceasta nu trebuie sa mai aiba o stare initiala. Tranzitiile (care vin sau pleaca) vor fi conectate direct de unul dintre substates. Aceste substates sunt intr-o relatie de tip OR, deci daca un obiect se afla intr-un composite state atunci el va fi in unul din aceste substates. Tranzitii: sagetile care reprezinta calea parcursa de un obiect pentru a trece dintr-o stare (stare sursa) in alta (stare destinatie). De obicei o tranzitie are atasat un eveniment. O tranzitie este reprezentata drept o sageata orientata de la state-ul sursa la cel destinatie. Langa aceasta sageata este un string cu urmatorul continut: “nume_tranzitie : trigger action [guard] / expression_of_action ^ send_clause”.

Trigger: arata, daca exista numele evenimentul care declanseaza tranzitia respectiva. UML nu necesita neaparat un trigger, daca este definit un guard.

Un eveniment nu este local, deci nu este vazut doar de o instanta a unei clase si este reprezentat prin numele sau si poate fi de mai multe feluri:

1. SignalEvent. Asociata cu un semnal, acest eveniment este produs de respectivul semnal. (signal = semnal transmis de regula cu ajutorul unei operatii adresat de regula unui alt obiect).

2. CallEvent. Asociata cu o operatie a unei clase, acest eveniment este produs de un apel a acelei operatii. Efectul ar fi ca pasii acestei operatii vor fi executati.

3. TimeEvent. Un eveniment cauzat de expirarea timpului. (timpul se calculeaza incepand de la producerea ultimului eveniment)

4. ChangeEvent. Un eveniment cauzat de o expresie particulara (a atributelor sau asocierilor) care devine adevarata..


O eroare poate fi considerata un eveniment. Pentru ca in UML nu exista un element special de modelare a unei erori ea va fi coniderata un tip de model careia ii vom atasa un stereotip de tip <<error>>.

Exista si posibilitatea ca o tranzitie sa nu aiba atasata nici un trigger nici un guard. Un exemplu avem in diagrama de mai jos unde tranzitiile de la o stare la alta au loc automat la terminarea activitatii interne a starii (Do-Activity).

Guard : este de fapt o conditie care este evaluata ori de cate ori un eveniment are loc. Evenimentul respectiv poate fi atasat tranzitiei in cauza sau nu. Tranzitia are loc daca aceasta conditie guard devine adevarata. O conditie de tip guard este evaluata o singura data, la momentul producerii evenimentului (daca conditia este falsa => evenimentul este pierdut).Daca nu exista un eveniment atasat tranzitiei ci numai un guard, tranzitia se va face cand expresia booleana a guardului va deveni adevarata.

Effect: arata, daca exista actiunea care se va face in momentul in care are loc tranzitia. O actiune este de fapt o abstractie a unei proceduri care poate schimba starea unui model. Daca exista mai multe actiuni , acestea vor aparea despartite de “ / ” si se vor executa pe rand incepand de la stanga. Intr-un metamodel UML pot exista mai multe tipuri de actiuni (este atomica si poate fi executata doar in timpul unei tranzitii):

1. CreateAction. Se creeaza o instanta a unui clase, interface, use-case, signal etc.2. CallAction. Actiunea de apeleare a unei anumite operatii3. AssignmentAction. O actiune in care se atribuie o valoare unui atribut sau pointer (referinta). 4. ReturnAction. O actiune prin care se intoarce o valoare apelantului anterior 5. SendAction. Asociata cu un semnal, aceasta actiune cauzeaza transmiterea semnalului.6. TerminateAction. Actiune prin care obiectul care invoca se va autodistruge.7. UninterpretedAction. Actiune folosita pentru a specifica o actiune specifica unui imbaj de programare care nu se poate clasifica in alt tip de actiune 8. DestroyAction. Actiune care distruge obiectul tinta.

O actiune este reprezentata intr-o diagrama prin textul care o descrie. Proprietatile unei actiuni sunt numele, expresia actiunii si limbajul de programare in care a fost scrisa expresia actiunii. Check-boxul Concurrent,atunci cand este bifat semnifica faptul ca composite state-ul este format din doua sau mai multe composite-states cu executie concurenta.In afara de proprietatile pe care oricare state le are un sub-state mai are si Subvertices care reprezinta o lista cu toate substate-urile continute

Pseudostates: 1. Starea initiala (defaultul) punctul de start cand starea obiectului nu are nici o

variabila care sa-l descrie si de asemenea nu realizeaza nici o activitate2. Branch: folosita pentru introducerea de alternative specificate prin diferite

conditii (guards)3. Forks: divide secventa de tranzitii in subsecvente concurente (care se executa in

acelasi timp)


4. Join: uneste anumite subsecvente (tranzitii concurente).5. History states: cateodata avem nevoie ca un obiect sa intre intr-o stare de

asteptare, iar apoi in momentul in care un anumit eveniment are loc, obiectul respectiv sa reintre in ultima stare dinainte de asteptare. Aceasta situatie este modelata folosind history states

6. Starea finala: reprezinta elementul care finalizeaza diagrama (intr-o diagrama poate sa existe sau sa nu existe)

Diagrama de stare a unui ascensor

Diagrama de stare a unei stiveLaborator 6

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 independent de use-cases, si folosite pentru:

reprezentarea actiunilor executate odata cu o operatie (instanta implementarii unei operatii)

reprezentarea activitatii interne a unui obiect a arata cum un set de actiuni pot fi execuate si cum vor afecta obiectele din jur a arata cum functioneaza anumite sisteme, referirea facandu-se la actori (muncitori),

organizare, cursul activitatii… Exemplu: 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 diagrama de activitate se concentreaza asupra actiunilor interne ale activitatilor si nu asupra actiunilor care apeleaza 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 in cod.

Notatiile diagramelor de activitate sunt foart asemanatoare cu a celor de stari (statechart diagram), de fapt conform specificatiilor UML o diagrama de activitate poate fi considerata o varianta 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 sunt conectate 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 face atunci 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 Adevarat sau 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 normal la 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 multe ori) tranzitia va avea loc atunci cand toate activitatile din action-state se vor termina.

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

Folosind un Fork, o tranzitie poate fi divizata in doua sau mai multe tranzitii. Aceste actiuni 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 corespunzatoare unor astfel de swimlanes vor fi plasate in interiorul dreptunghiurilor. Fiecarui swimlane ii este dat un nume, care este pus in partea superioara a dreptunghiului.


Pt use-case-ul admitere facultate Pt use-case-ul scoala de soferi


Laborator 7

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 unui

sistem. 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 a relatiilor dintre obiecte. Spre deosebire de diagramele de tip sequence, ele nu se concentreaza pe succesiunea in timp a interactiunilor ci mai degraba pe conexiunile structurale dintre obiectele care colaboreaza si pe rolurile pe care acestea le joaca in cadrul unei colaborari.

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 interactiune intr-un sistem.

O diagrama de colaborare descrie un set de obiecte impreuna cu relatiile dintre ele precum si interactiunile dintre acestea, adica felul in care respectivele obiecte coopereaza pentru a defini functionalitatea unui sistem sau subsistem. Este foarte utila modelarea interactiunilor pentru 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 poate reprezenta 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 care mesajele 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 sau colaborare. Mesajele (stimulii) sunt folositi pentru a descrie interactiunea dintre obiecte si lor li se pot atasa cate o eticheta-mesaj care defineste printre alte lucruri si un numar de secventa pentru mesajul respectiv. Mesajul acesta va fi de cele mai multe ori un apel de procedura (operatie), ca in figura de mai jos.

Collaboration

Role

Class

role name

role name

role name

role name


Un actor trimite un mesaj pentru printare catre un computer. Computerul trimite un mesaj de printare serverului, care la randul lui va trimite un mesaj de imprimare catre imprimanta (daca aceasta 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 fi folosite pentru doua mesaje care vor fi trimise in paralel. Un Link este o conexiune dintre doua obiecte care colaboreaza. Mesajele (stimulii) vor fi

pozitionati de-a lungul acestora.Rolul jucat de un obiect intr-o colaborare va fi aratat la capetele link-urilor. Unui

astfel de rol i se pot atasa diferite stereotipuri cum ar fi:- global: specifica faptul ca instanta respectiva este vazuta in intregul sistem si poate fi

apelata folosind un nume cunoscut oriunde in sistem- local: specifica faptul ca instanta respectiva este vazuta deoarece este o variabila locala

intr-o operatie.- parameter: specifica faptul ca instanta respectiva este vazuta deoarece este un parametru a

unei operatii- association: specifica faptul ca instanta respectiva este vazuta doar de catre obiectele

aflate in asociere- self: specifica faptul ca instanta respectiva este vazuta doar de catre ea insasi

Obiectelor create in timpul unei colaborari vor avea constrangerea {new}, iar cele care sunt distruse in timpul colaborarii vor avea constrangerea {destroyed}. Obiectele care sunt si create si distruse in cadrul aceleiasi colaborari vor avea constrangerea {transient}care este echivalenta 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 din diagrama 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 continua cu 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 detalii despre 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 este dat 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 toate operatiile (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 sau poate fi considerata implicita la terminarea operatiei care se ocupa de mesajul transmis.- asincrone: sunt folosite acolo unde nu exista o reintoarcere explicita in cadrul obiectului care initiaza mesajul, acesta continuandu-si executia dupa transmiterea mesajului, fara sa astepte rezultatul operatiilor care se vor executa odata cu transmiterea mesajului; acest tip de 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 la timp pot fi adaugate diagramelor de colaborare, insa nu asa clar ca intr-o diagrama de tip sequence. Aceste adnotari vor fi de fapr notite sau constrangeri atasate diferitelor elemente din diagrama.

Diagrama de colaborare din figura de mai sus arata interactiunile care au loc cand un senzor 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 catre toate 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 declansarea alarmei 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 isi extrage noile sarcini din coada sa.


Laborator 8

Sequence Diagram

O diagrama de secventa este o diagrama ce descrie structura dinamica a unui sistem aratand interactiunile dintre instantele unor clase (obiecte) in momentul rularii programului (functionarii sistemului), oferind o harta a modului de transmitere a mesajelor intre obiecte in timp (=> se modeleaza operatiile care vor trebui incluse in clasele sistemului precum si evenimentele suportate de clase).

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 la aparitia 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 generate in urma interactiunilor dintre obiecte.

Asadar o diagrama de secventa va reprezenta un scenariu Use Case (sau o parte a unui scenariu 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 momentul in care apar (functie de timp)- dimensiunea orizontala: arata obiectele catre care sunt trimise mesajele (Obiectele implicate sunt listate de la stanga la dreapta dupa momentul in care sunt implicate in secventa de mesaje)

Obiectele care vor participa la interactiuni vor avea urmatoarea sintaxa: InstantaClasa : NumeClasa (ex. myReportGenerator : ReportGenerator).

Ca notatie UML, o diagrama de secventa va consta dintr-un set de obiecte, fiecare avand o 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 o instanta 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 in cadrul 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 de interactiuni. • Destroy stimuli - Folosit pentru a distruge un obiect la un anumit dat in cadrul secventei de interactiuni. Linia vietii acelui obiect care va fi distrus se va termina printr-o cruce in momentul trimiterii stimulului.


O diagrama de secventa este foarte simplu de citit, ea ilustrand succesiunea in care obiectele isi vor juca rolul inr-un anumit scenariu precum si diferitele apeluri intre aceste obiecte. Asadar, pentru citirea unei diagrame de secventa se incepe de la coltul din stanga sus, unde va fi instanta care va incepe secventa. Apoi se urmeaza sagetile, sau mesajele, de sus in jos, tinandu-se cont de faptul ca return messages sunt optionale.

Interactiunea dintre obiecte este descrisa specificand diferitele tipuri de mesaje schimbate de acestea. Mesajele sau stimulii pot fi de mai multe feluri (simple, sincrone, asincrone), care difera in reprezentare prin forma varfului sagetii care este simbolul grafic pentru un mesaj.

Clasele active sunt folosite sa modeleze comportamentul concurent al lumii reale, si sa creeze un model care foloseste resursele sistemului cat de eficient posibil.. O clasa activa este o clasa care poseda un fir de executie si poate initia si controla o activitate. O clasa activa (respectiv un obiect al acestei clase) isi executa operatiile in paralel cu alte obiecte active si initiaza actiuni de una singura (prin propriul cod sau prin prin trimiterea mesajelor altora).

In contrast cu clasele active sunt clasele pasive, care sunt toate clase “normale” in sistem. Un obiect pasiv (a unei clase pasive) este capabil sa execute numai cand alte cateva obiecte (pasive sau active) executa cateva operatii pe el (ii trimite un mesaj).

Asadar dupa cum am vazut obiectele pot fi de doua tipuri: active si pasive dupa tipul claselor de care apartin.

Se poate specifica obiectul care are controlul prin bifarea check-boxului Active. In acel moment se va schimba si reprezentarea grafica a obiectului (o bordura mai groasa plus linia vietii se schimba din linia punctata intr-un dreptunghi).

In Poseidon, toate tipurile de mesaje (stimuli), in afara de create stimuli, pot fi trimisi la obiectul care le initiaza..

Cand un mesaj este primit se porneste o activitate in obiect. Vom spune ca obiectul respectiv se va activa. O activare arata perioada de timp in timpul in care un obiect va face o actiune (operatie implementata in clasa din care provine) sau asteapta executia unui alt obiect catre care a trimis un mesaj mai devreme. O activare este reprezentata drept un mic dreptunghi avand partea de sus aliniata cu punctul in care se initiaza activitatea si cu partea de jos aliniata cu punctul in care se termina activarea. Dreptunghiul acesta numit bara de activare reprezinta de fapt durata executiei mesajului. Cand un obiect primeste un stimul (mesaj), o activare existenta este terminata la coada sagetii care pleaca. Exista insa si doua exceptii de la aceasta regula, deci cand obiectul care trimite mesajul va ramane activ: cand mesajul trimis este asincron (sent stimulus) cand obiectul care transmite mesajul este activ (are bifat checkboxul respectiv in tabul Properties)

Ca si in diagramele de colaborare mesajele pot avea numere de secventa insa acestea sunt rareori folosite deoarece succesiunea mesajelor este data explicit intr-o diagrama de secventa.


Crearea unui raport cu privire vanzarea de Cd-uri la un magazin de profil.

Obiectul aServlet trimite un mesaj unei instante a clasei ReportGenerator numita gen. Mesajul este etichetat cu generateCDSalesReport, ceea ce inseamna ca ReportGenerator va implementa handler-ul acestui tip de mesaj; cdId este o variabila trimisa in cadrul mesajului (=> se afla intre paranteze). La primirea mesajului gen trimite un mesaj de tip create stimulus catre clasa CDSalesReport (=> se creeaza o instanta a acestei clase numita aCDReport care este returnata lui gen printr-un return stimulus). Apoi instanta gen face apeluri catre acest aCDReport, caruia ii paseaza parametrii la fiecare apel (data, saptamana, vanzari). La sfarsitul secventei, gen va returna acest aCDReport catre aServlet.


Laborator 9

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. In Poseidon se pot edita chiar si Object Diagrams in cadrul sectiunii diagramei Deployment deoarece s-au introdus si notatiile pentru Object in toolbar-ul aferent.

O 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 din cadrul 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 detaliere foarte mic, sau la un nivel inferior (low-level) unde vor fi ilustrate componentele pana la nivelul package-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 apoi identificarea componentelor software si a interfetelor acestora. O data ce interfetele au fost definite si acceptate de echipe este mult mai usor de organizat efortul de dezvoltare al subechipelor.

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 ca dependentele 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 sub forma unor componente. Componentele sunt de fapt fisierele existente in mediul de dezvoltare folosit pentru constructia unui system. Ele sunt blocurile care alcatuiesc sistemul distribuit pe diferite alte elemente hardware (aceste elemente hardware pot fi si computere diferite). De fapt ele sunt artefacte de nivel inalt cum ar fi java beans, dll-uri, ocx’s-uri si alte produse software, de multe 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 a conceptelor si functionalitatilor definite in arhitectura logica (clase, obiecte, diferite relatii si colaborari). Fiecare componenta va oferi servicii altor componente (numite clienti), aceste servicii 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

O componenta software poate fi:


source component (Compile-Time Components): 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 tipPentru Compile-Time Components se pot folosi urmatoarele stereotipuri:

- <<file>>: fisier continand cod sursa- <<page>>: o reprezentare a unei pagini web- <<document>>: reprezentate a unui fisier continand documentatie nu cod

binary component (Link-Time Component): cod obiect care este rezultatul compilarii a unuia sau mai multor componente sursa; 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 sau in cazul unei librarii dinamice la run-time (o astfel de biblioteca este incarcata de o componenta executabila doar in momentul rularii)

Pentru Link-Time Components se pot folosi urmatoarele stereotipuri:- <<process>>: simplu proces- <<thread>>: fir de executie

executable component (Run-Time Component): un fisier executabil (exe) care este rezultatul procesului de linking al tuturor componentelor binare (statrice la link-time si dinamice la 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:- <<application>>: reprezinta un fisier executabil- <<table>>: o reprezentare a unui tabel dintr-o baza de date folosit drept

componenta la run-timeSa presupunem ca dorim sa construim un software pentru muzica de pe CD-uri (un

player) a carui interfata, simpla ar include doar butoanele obisnuite . Atunci am avea urmatoarea diagrama de componenta:


In UML o componenta este ilustrata sub forma unui dreptunghi uneori avand o elipsa plus inca doua mici dreptunghiuri in stanga. 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 relatie

de dependenta daca o clasa localizata intr-o anumita componenta este schimbata atunci acest lucru nu

trebuie sa afecteze clase din afara componentei respective daca o clasa dintr-o componenta trebuie sa fie reutilizata va trebui sa fie reutilizate toate

clasele incluse in acea componenta (niciodata nu se va reutiliza numai o parte a unui element software)

abstractiile nu trebuie sa depinda de detalii ci detaliile vor trebui sa depinda de abstractii elementele software vor trebui sa fie deschise pentru extindere dar inchise pentru

modificare daca A depinde de B atunci B ar trebui sa fie mai stabila (mai putin probabil de a suferi

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

afectata stabilitatea.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 altor sisteme.

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

O sageata punctata intre doua componente inseamna ca o componenta are nevoie de o alta pentru a fi definite complet. O astfel de dependenta intre o source component A si o source component B inseamna ca, o schimbare in B necesita o recompilare si a lui A. Daca componentele intre care exista o dependenta sunt executabile atunci citind o astfel de diagrama vom putea identifica de ce librarii dinamice are nevoie un program pentru a putea rula.

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 fi definite la nivel cod (ex: interfete Java) sau binary, folosite la run-time (ex. OLE).

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 folosi notatia tip lollypop. Incepand cu UML2 a fost introdusa simbolul de socket pentru a indica faptul ca 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 <<require>>).

Un port (notatia UML = patrat mic), va fi o caracteristica a unei componente ce specifica un punct de interactiune a componentei cu mediul extern. Aceste porturi care pot avea si un nume vor 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 Reporting Tool 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 deployment diagram.

O deployment diagram sa o network diagrams cum i se mai spune descrie felul cum componentele sunt repartizate pe diferitele computere existente in cadrul unui sistem. 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) diferitele componente si cum vor comunica una cu alta, asadar s-ar putea spune ca o deployment diagram modeleaza sistemul la run-time.

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


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

Diagrama arata componenta Reporting Tool desenata inauntul componentei IBM WebSphere, care 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 folosind interogari SQL. Componenta Report Tool comunica folosind SOAP over HTTPS cu Billboard Service.


Laborator 10

Caz de studiu

In urmatoarele doua laboratoare ne propunem sa realizam modelul unei aplicatii care sa ruleze in cadrul unui bancomat si sa realizeze principalele functii ale acestuia (retragere bani si citire sold), incercand abordarea acestui model din mai multe puncte de vedere sau altfel spus vom prezenta mai multe viziuni (vederi) asupra proiectului realizat.

Asadar viziunile (vederile) arata diferite aspecte ale sistemului modelat. Numai definind un numar de viziuni, fiecare aratand un aspect particular al sistemului se poate construi imaginea completa a sistemului. Privind sistemul prin viziuni diferite este posibila concentrarea pe un anumit aspect al sistemului la un moment dat.

Fiecare vedere este descrisa intr-un numar de diagrame continand informatie care descrie un aspect particular al sistemului. Exista si o mica suprapunere, astel incat o diagrama poate face parte din mai multe viziuni. O diagrama, facand parte dintr-o anumita vedere trebuie sa fie destul de simpla pentru a fi usor de inteles si a fi coerenta cu celelalte diagrame si viziuni, scopul principal fiind acela de a contura o imagine clara si completa a sistemului incluzand toate functionalitatile pe care acesta le va avea.

In limbajul UML sunt definite urmatoarele tipuride viziuni: Use-case view: vederea centrala (pe baza ei se vor contura celelalte vederi) aratand

functionalitatea unui sistem asa cum este perceputa de actorii externi (cei care interactioneaza cu sistemul); aceasta vedere este descrisa de obicei prin diagrame de tip use-case si activity insa se pot folosi orice tip de diagrame care ne-ar putea ajuta sa ne atingem scopul. Aceasta vedere este pentru clienti, designeri, dezvoltatori, si inginerii de testare, la sfarsitul proiectarii trebuie ca sistemul sa indeplineasca toate functionalitatile care au fost propuse in aceasta vedere.

Logical view: o vedere aratand cum functionalitatea va fi implementata in cadrul unui sistem, in contrast cu Use-case view, aici vom privi in interiorul sistemului descriind atat structura statica (clase, obiecte, relatii implementate in diagrame de tip class si objects) cat si cea dinamica a sistemului (mesaje transmise intre obiecte in momentul functionatii sistemului implementate in diagrame de tip state, sequence, collaboration si activity). Aceasta vedere este pentru designeri si dezvoltatori.

Component view: o vedere aratand organizarea si structura componentelor (de cod) si relatiile (dependentele) dintre acestea. Aceasta vedere este pentru dezvoltatori si va fi implementata cu ajutorul diagramelor de tip component.

Concurrency view: o vedere care se va concentra pe problemele de comunicare si sincronizare care sunt prezente in sistemele concurente in timp real. Aici se va prezenta modul in care sistemul va fi divizat in procese si procesoare, o astfel de vedere va fi folosita de dezvoltatori si de cei care se ocupa cu integrarea sistemului si va consta din diagramele pentru descrierea structurii dinamice a sistemului.

Deployment view: o vedere aratand modul in care va fi desfasurat sistemul in arhitectura fizica (formata din computere si alte sisteme hardware). Aceasta vedere este pentru dezvoltatori, integratori si testeri si va fi implementata prin diagramede tip deployment.


Inginerie software - proiecte

1. Aplicatie folosita in cadrul procesului de admitere la o universitate. Vor trebui acoperite : gestionare a bazelor de date de date, calcularea mediilor de admitere functie de diferitele criterii (pe facultati), ordonarea acestor medii...

2. Administrarea unui parc de automobile. Informaţiile relative la un automobil sunt: nr. de locuri, puterea, marca, nr. de înmatriculare, tipul de carburator (benzină sau motorină), natura (break, berlină, decapotabilă). Se va permite intrarea unei maşini, ieşirea unui maşini, înlocuirea unei maşini cu alta de acelaşi model (având alt număr de înmatriculare).

3. Administrearea funcţionarii unei staţii meteorologice. Se va permite citirea temperaturilor din oră în oră, precum şi cantităţile zilnice de precipitaţii dintr-o anumită lună a anului. Apoi se va permite afişarea temperaturilor maxime (împreună cu ziua şi ora asiciată), temperatura minimă (cu ziua şi ora asociată), lista zilelor, ordonată descrescător în funcţie de cantitatea de precipitaţii, media precipitaţiilor zilnice dintr-o anumită lună a anului.

4. Aplicatie de gestionare a unui concurs sportiv. Aceasta va permite stocarea într-un fişier a datelor sportivilor şi a punctajelor acestora. Aplicatia va trebui modelata astfel incat sa acopere toate detaliille organizatorice a acestui concurs, inclusiv masa, cazarea sportivilor, vanzarea de bilete s.a.m.d.

5. Aplicatie folosita in cadrul procesului de recensamant, la nivel de tara. Aceasta va permite crearea de diferite statistici referitoare la locul naşterii unor persone, varsta populatiei dintr-un anumit judet sau localitate s.a.m.d.

6. Modelarea unui magazin virtual, care sa aiba toate facilitatile oferite cumparatorilor dar si un mod de administrare usor prin logare prin internet folosind semnaturi digitale. In plus se cere modelarea unui subsistem care sa verifice zilnic cursurile BNR a principalelor monede (dolarului + euro), precum si site-urile principalilor furnizori pt colectarea anumitor date aflate pe o anume pagina dinamica.

7. Aplicatie pentru gestionarea unei biblioteci. Se cere administrarea personalului, cartilor si a cititorilor. Personal: date personale, salariu, incadrare, vechime, programde lucru, planificarea pt concedii etc. Carti: titlu, autor, ISBN, frecveta imprumautarii, ultima zi a inapoierii etc. Cititori: date personale, domeniu de interes, etc.

8. Agenda telefonica, lucrand cu baze de date, accesibila pe Net, care sa permita principalele operatii suportate de o agenda telefonica (introducere inregistrare, stergere inregistrare, modificare inregistrare, cautare inregistrare, vizualizare inregistrari agenda). In plus agenda va avea o sectiune pt administrare care seva face prin specificarea unui username si a unei parole.


9. Aplicatie pentru rulare de fisiere audio, asemanatoare Winamp. Cerintele sunt: sa aiba prinipalele functionalitati (butoane Play, Stop, ….), sa includa un Playlist unde se pot introduce doar fisiere audioacceptate, sa se poata face cautarea in playlist dupa cuvinte cheie etc.

10. Aplicaţie pentru administrarea unei benzinării, deci care să ajute atât la gestionarea stocurilor de benzină (mai multe tipuri), motorină etc, cât şi să înregistreze plata, eventual in orice fel de monedă… Totodată se doreşte o administrare a angajaţilor şi a o rarului lor zilnic şi săptămânal.

!!! Toate proiectele chiar si care nu specifica vor trebui sa includa folosirea unor baze de date (sau fisiere externe), folosirea de interfete grafice (eventual pagini html), iar diferitele componente sa ruleze pe masini diferite. Fiecare model va trebui sa includa diagrame de tip Use-Case, Class, Activity, Sequence, State, Deployment.

introducere in uml

Documents