UML

  • 560 views
Uploaded on

2011

2011

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
560
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Istorie În principal, UML este fuziunea metodologiilor dezvoltate de Grady Booch, James Rumbaugh (numită OMT – Object Modeling Technique) şi Ivar Iacobson (numită OOSE – Object-Oriented Software Engineering). Unificarea a avut loc în anul 1995, când a fost emisă prima specificaţie a limbajului (versiunea UML 0.9). Primul standard (UML 1.1) a fost stabilit în 1997 de către asociaţia OMG (Object Management Group) la care au aderat numeroase firme de software (Microsoft, IBM, Sun, Oracle, etc.) şi personalităţi din acest domeniu. Ulterior au avut loc mai multe revizii şi noi versiuni.
  • 2. Istorie
  • 3. Cine a stat la baza UML
  • 4. Clasificare
  • 5. Model al unui sistem complex în notaţia UML
  • 6. Diagrama USE CASE Diagramele de utilizare – use-case diagrams – sunt folosite pentru a specifica modul de funcţionare a entităţii (sistem, subsistem sau clasificator) aşa cum se manifestă din punct de vedere al interacţiunilor cu mediul exterior. Cazul de utilizare se foloseşte pentru specificarea particularităţilor comune ale comportării unui sistem sau a oricărei alte entități în domeniul de lucru fără cercetarea structurii interne a acestei entităţi. Actorul reprezintă orice entitate externă sistemului modelat, care colaborează cu sistemul şi utilizează posibilităţile lui funcţionale pentru atingerea anumitor scopuri .
  • 7. Diagrama USE CASE Relații dintre actori și cazuri de utilizare:• Asociere (association relationship)• Extindere (extend relationship)• Generalizare (generalization relationship)• Cuplare (include relationship)
  • 8. Diagrama USE CASE (exemplu)
  • 9. Diagrama de secvență Diagramele de secvenţă se utilizează pentru modelarea colaborării între obiecte în limbajul UML. În diagrama de secvenţă se reprezintă numai obiectele care acţionează şi nu se reflectă asocierile statice cu alte obiecte. Pentru diagrama de secvenţă momentul principal este dinamica colaborării între obiecte în timp. Stereotipuri:
  • 10. Diagrama de secvență Stereotipuri de mesaje:• "call" – invocă o operaţie sau procedură a obiectului-destinatar;• "return" – returnează valoarea operaţiei executate obiectului apelant;• "create" – crează alt obiect pentru executarea anumitor acţiuni;• "destroy" – distruge un obiect. Se transmite în caz dacă este necesar a termina acţiunile din partea obiectului existent sau dacă obiectul trebuie să elibereze resursele alocate;• "send" – trimite un semnal unui obiect care se iniţializează asincron de către un obiect şi este acceptat de altul. Diferenţa între un semnal şi un mesaj constă în fapt că semnalul trebuie să fie descris în clasa obiectul căreia iniţializează transmiterea lui.
  • 11. Diagrama de secvență (exemplu)
  • 12. Diagrama de colaborare Diagramele de colaborare arată interacţiunea dintre obiecte intr-o situaţie concretă. Spre deosebire de diagramele de secven ță care pun accent pe interacţiunea exprimată în timp, diagramele Collaboration arată legăturile logice intre obiecte. Obiecte sunt elementele de bază sau primitivele grafice din care constă diagrama de colaborare.
  • 13. Diagrama de colaborare Colaborarea este interacțiunea dintr-o totalitate de elemente care produc un efect colaborativ. Legătura (link) este exemplarul sau exemplul asocierii arbitrare. Legătura ca element al limbajului UML poate fi între două sau mai multe obiecte. Tipuri de legături:• "association" – asociere (se presupune implicit, de aceea acest tip poate să nu fie indicat).• "parameter" – parametrul metodei. Obiectul respectiv poate să fie doar paramentru al unei metode.• "local" – variabila locală a metodei. Domeniul ei de vizibilitate este limitat de către obiectul vecin.• "global" – variabila globală. Domeniul ei de vizibilitate este toată diagrama de colaborare.• "self" – legătura reflexivă a obiectului care presupune transferul mesajelor către sine. În diagrama de colaborare legătura reflexivă se reprezintă în formă de buclă în partea de sus al dreptunghiului obiectului.
  • 14. Diagrama de colaborare (exemplu)
  • 15. Diagrama de stare O diagramă de stare este utilizată pentru a reprezenta stările unei clase date, evenimentele ce cauzează tranziţiile de la o stare la alta, şi acţiunile care rezultă din schimbările starilor. În limbajul UML starea este subînţelesă ca metaclasă abstractă, ce se utilizează pentru modelarea situaţiei aparte, pe parcursul căreia este prezentă executarea unei anumite condiţii. Starea iniţială și starea finală reprezintă un caz particular de stare, care nu conţine nici o acţiune internă (pseudostare).
  • 16. Diagrama de stare O simplă tranziţie reprezintă o relaţie între două stări consecutive indicînd faptul schimbării a unei stări cu altă. Evenimentul reprezintă specificaţia anumitui fapt, care are ataşată o locaţie în timp şi în spaţiu. Condiția gardă este o expresie booleana care se scrie în paranteze dreptunghiulare, evenimentul are loc numai dacă condi ția garda are valoare adevărată. Expresia acţiunii (action expression (effect)) se execută atunci şi numai atunci cînd se execută tranziţia.
  • 17. Diagrama de stare (exemplu)
  • 18. Diagrama de activitate O diagramă de activităţi este o variantă a diagramelor de stări organizată în raport cu acţiunile şi destinația în primul rînd reprezentării comportamentului intern al unei metode (implementarea unei operaţii) sau a unui caz de utilizare. Reprezentarea grafica a unei activităţi: Tranziția transmite activitatea în următoarea stare imediat după ce se termină acţiunea din starea precedentă.
  • 19. Diagrama de activitate Fork (diviziunea – concurrent fork) are o tranziţie de intrare şi mai multe de ieşire (a). Join (unirea – concurrent join) invers are mai multe tranziţii de intrare şi numai o tranziţie de ieşire (b). Starea iniţială și starea finală: Decizia:
  • 20. Diagrama de activitate (exemplu)
  • 21. Diagrama de clase Diagrama claselor arată diferite clase din care este compus sistemul. Diagrama arată operaţiile (metodele) şi atributele (variabile) claselor precum şi structura statică a claselor sistemului, adică ce clase “se cunosc” sau ce clase fac parte din altele. Clasa - clasă este o noţiune de bază în Object Oriented Programming. O clasă are nume şi este compusă din atribute şi metode.
  • 22. Diagrama de clase Atributele - în UML, atributele sunt prezentate cel puţin prin numele lor, dar pot arăta şi tipul lor, valoarea iniţială şi alte proprietăţi. Atributele sunt afişate cu vizibilitatea lor:• + pentru atributele public• # pentru atributele protected• - pentru atributele private Operaţiile - operaţiile (sau metodele) sunt prezentate şi ele cel puţin prin numele lor, dar pot avea şi lista parametrilor şi tipul valorii returnate. Generalization (moştenire). Moştenirea este conceptul de bază al Object Oriented Programming, în care o clasă derivată “moşteneşte” de la părintele ei toate atributele şi metodele, poate redefini unele dintre acestea şi poate adăuga propriile ei metode şi atribute.
  • 23. Diagrama de clase Associations (asociere). Asocierile indică relaţiile intre clase şi definesc semantica şi structura conexiunilor intre obiecte. Aggregation (agregare) este o formă specială de asociere cand două clase asociate nu au acelaşi statut, ci formează o interacţiune de tip “parte-intreg”. Composition (compoziţia) este o formă de agregare, insă aici relaţia “parte- intreg” este atât de stransă incat părţile nu pot exista separat, ci doar ca părţile întregului. Dependency (dependența). Atunci când o clasă depinde de o altă clasă, în sensul că utilizează acea clasă ca şi atribut al său.
  • 24. Diagrama de clase Realization (realizare). Aste relația prin care unul dintre elemente „garantează” realizarea unor acţiuni prin intermediul celuilalt element. Interfeţele sunt exemplarele diagramelor cazurilor de utilizare. Obiectul (object) este un exemplar special al clasei, care este creat în timpul executării programului. El are un propriu nume şi valoare concretă a atributelor.
  • 25. Diagrama de clase (exemple)
  • 26. Diagrama de clase (exemple)
  • 27. Diagrama de clase (exemple)
  • 28. Diagrama de componente Diagrama componentelor reprezintă modelul la nivel fizic. În ea se reflectă componentele de întreţinere a programului, a sistemului şi legăturile dintre ele. Component (Component) – această pictogramă reprezintă un modul de program cu o oarecare interfaţă bine determinată. Specificatorul şi corpul subprogramului (Subprogram Specification and Body) – aceste pictograme arată specificarea vizuală a programului şi corpul realizării lui. De obicei programele sunt alcătuite din componente standarte (subroutines) şi conţin clase concrete.
  • 29. Diagrama de componente Programul principal (Main Program) – reprezintă un fişier, care conţine codul sursă a programului principal. El conţine rădăcina programului. Specificatorul şi corpul pachetului (Package Specification and Body) – pachetul în cazul dat reprezintă realizarea clasei. Specificatorul pachetului conţine informaţii despre prototipurile funcţiei clasei. În C++ acest fişier este fişierul cu extensia *.h. Corpul pachetului conţine codul operaţiilor clasei. În C++ această informaţie se conţine în fişierul cu extensia *.cpp.
  • 30. Diagrama de componente Specificatorul şi corpul sarcinei (Task Specification and Body) – aceste pictograme reprezintă pachetele, care au un flux independent de conducere. Fişierele executabile de obicei au extensia *.exe. Componentul în Enterprise Arhitect:
  • 31. Diagrama de componente (exemple)
  • 32. Diagrama de componente (exemple)
  • 33. Diagrama de componente (exemple)
  • 34. Diagrama de plasare Scopurile diagramei de plasare:• Definirea distribuirii componentelor a sistemului după nodurile fizice.• Reprezentarea legăturilor fizice între toate nodurile de realizare a sistemului la etapa de executare.• Găsirea locurilor înguste a sistemului şi reconfigurarea topologiei ei pentru atingerea producerii necesare. Nodul (node) este un element real (fizic) al unui sistem care reprezintă un mijloc de calcul cu un anumit volum de memorie
  • 35. Diagrama de plasare (exemple)
  • 36. Diagrama de plasare (exemple)
  • 37. Diagrama de plasare (exemple)
  • 38. Diagrama de plasare (exemple)
  • 39. Diagrama de pachete Pachetul (package) un container logic pentru elemente ˆîntre care se stabilesc legături. Definește un spațiu de nume. Toate elementele UML pot fi grupate ˆ în pachete (cel mai des pachetele sunt folosite pentru a grupa clase). Un pachet poate conține subpachete => se creează o structură arborescentă (similară cu organizarea fișierelor/directoarelor).
  • 40. Diagrama de pachete Relații:• Dependență <<access>> = import privat• Dependență <<import>> = import public Utilitatea pachetelor:• ˆÎmpart sisteme mari ˆ în subsisteme mai mici și mai u șor de gestionat.• Permit dezvoltare paralelă iterativă.• Definirea unor interfețe clare ˆ între pachete promoveaz refolosirea codului (ex. pachet care oferă funcții grafice).
  • 41. Diagrama de pachete (exemple)
  • 42. Diagrama de pachete (exemple)
  • 43. Reverse engineering Ingineria inversă este procesul de analiză aunui sistem existent pentru a identificacomponentele sale şi interdependenţele lor şipentru a crea reprezentări a sistemului la un nivelridicat de abstractizare. În cele mai multe cazuri, inginerie inversă seutilizează pentru a prelua documentele lipsă dedesign de la codul sursă existent pentru studia atâtstructura statică cît şi comportamentul dinamic alunui sistem.
  • 44. Utilizarea diagramelor în cadrul unui proiect
  • 45. Mulțumesc pentru atenție!