UML

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.

Model al unui sistem complex în notaţia UML

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 .

Diagrama USE CASE
 Relații dintre actori și cazuri de utilizare:
• Asociere (association relationship)

• Extindere (extend relationship)

• Generalizare (generalization relationship)

• Cuplare (include relationship)

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:

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.

Diagrama de secvență (exemplu)

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.

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.

Diagrama de colaborare (exemplu)

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

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.

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ă.

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:

Diagrama de activitate (exemplu)

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.

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.

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.

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.

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.

 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.

 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:

Diagrama de componente (exemple)

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

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

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

Reverse engineering
Ingineria inversă este procesul de analiză a
unui sistem existent pentru a identifica
componentele sale şi interdependenţele lor şi
pentru a crea reprezentări a sistemului la un nivel
ridicat de abstractizare.

În cele mai multe cazuri, inginerie inversă se
utilizează pentru a prelua documentele lipsă de
design de la codul sursă existent pentru studia atât
structura statică cît şi comportamentul dinamic al
unui sistem.

Utilizarea diagramelor în cadrul unui proiect

UML

More Related Content

Viewers also liked (15)

UML