Diagrama UML

 [ascunde] 

• 1 Istoric
• 1.1 Înainte de UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Design
• 2.1 Metode de dezvoltare software
• 2.2. Modelarea
• 3 Diagrame
• 3.1 Diagrame de structură
• 3.2 Diagrame de comportament
• 3.2.1 Diagrame de interacțiune
• 4 Meta-modelarea
• 5 Adopție
• 6 Critici
• 6.1 Critica UML 1.x

Istoria metodelor și notațiilor orientate pe obiecte

UML a evoluat din a doua jumătate a anilor 1990 și își are rădăcinile în metodele orientate pe obiecte dezvoltate la sfârșitul anilor 1980 și începutul anilor 1990. Cronologia (a se vedea imaginea) prezintă cele mai importante aspecte ale istoriei metodelor și notațiilor de modelare orientate pe obiecte.

Inițial, se bazează pe notațiile metodei Booch, pe tehnica de modelare a obiectelor (OMT) și pe ingineria software orientată pe obiecte (OOSE), pe care le-a integrat într-un singur limbaj. ^[5]

Înainte de UML 1.x[modificare sursă | modificare]

Rational Software Corporation l-a angajat pe James Rumbaugh de la General Electric în 1994 și, după aceea, compania a devenit sursa a două dintre cele mai populare abordări de modelare orientate pe obiecte ale momentului:^[6] Object-modeling technique (OMT) a lui Rumbaugh și metoda lui Grady Booch. Aceștia au fost curând ajutați în eforturile lor de Ivar Jacobson, creatorul metodei de inginerie software orientată pe obiecte (OOSE), care li s-a alăturat la Rational în 1995. ^[1]

Sub conducerea tehnică a celor trei (Rumbaugh, Jacobson și Booch), un consorțiu numit UML Partners a fost organizat în 1996 pentru a finaliza specificația limbajului de modelare unificat (UML) și pentru a o propune Grupului de gestionare a obiectelor (OMG) în vederea standardizării. Parteneriatul conținea și alte părți interesate (de exemplu HP, DEC, IBM și Microsoft). Proiectul UML 1.0 al partenerilor UML a fost propus de consorțiu către OMG în ianuarie 1997. În cursul aceleiași luni, partenerii UML au format un grup, menit să definească semnificația exactă a construcțiilor limbajului, prezidat de Cris Kobryn și administrat de Ed Eykholt, pentru a finaliza specificația și a o integra cu alte eforturi de standardizare. Rezultatul acestei activități, UML 1.1, a fost prezentat la OMG în august 1997 și adoptat de OMG în noiembrie 1997. ^[1][7]

UML 1.x[modificare sursă | modificare]

După prima versiune, a fost format un grup de lucru ^[1]pentru a îmbunătăți limbajul, care a lansat mai multe revizuiri minore, 1.3, 1.4 și 1.5. ^[8]

Standardele pe care le-a produs (precum și standardul original) au fost considerate ambigue și inconsistente. ^[9][10]

UML 2.x[modificare sursă | modificare]

Revizuirea majoră a UML 2.0 a înlocuit versiunea 1.5 în 2005, care a fost dezvoltată cu un consorțiu extins pentru a îmbunătăți în continuare limbajul și pentru a reflecta noua experiență privind utilizarea caracteristicilor sale. ^[11]

Deși UML 2.1 nu a fost niciodată publicată ca specificație oficială, versiunile 2.1.1 și 2.1.2 au apărut în 2007, urmate de UML 2.2 în februarie 2009. UML 2.3 a fost lansat oficial în mai 2010.^[12] UML 2.4.1 a fost publicată oficial în august 2011.^[12] UML 2.5 a fost lansat în octombrie 2012 ca versiune "În curs de elaborare" și a fost lansat oficial în iunie 2015. ^[12]

Specificația UML 2.x are patru părți:

1. Suprastructura care definește notația și semantica pentru diagrame și elementele lor de model.
2. Infrastructura care definește metamodelul de bază pe care se bazează suprastructura.
3. Limbajul Object Constraint Language (OCL) pentru definirea regulilor pentru elementele modelului.
4. Schimbul de diagrame UML, care definește modul în care se face schimbul de layout-uri de diagrame UML 2.

În continuare sunt prezentate versiunile actuale ale acestor standarde: UML Superstructure versiunea 2.4.1, UML Infrastructure versiunea 2.4.1, OCL versiunea 2.3.1 și UML Diagram Interchange versiunea 1.0.^[13] Acesta continuă să fie actualizat și îmbunătățit de către grupul operativ de revizuire, care rezolvă orice problemă a limbajului. ^[14]

Limbajul de modelare unificat (UML) oferă o modalitate de a vizualiza planurile arhitecturale ale unui sistem într-o diagramă (a se vedea imaginea), incluzând elemente precum: ^[5]

• Orice activități (locuri de muncă)
• Componentele individuale ale sistemului
• Și modul în care acestea pot interacționa cu alte componente software.
• Cum va funcționa sistemul
• Modul în care entitățile interacționează cu altele (componente și interfețe)
• Interfață utilizator externă

Deși inițial a fost conceput exclusiv pentru documentația de proiectare orientată pe obiecte, limbajul de modelare unificat (UML) a fost extins pentru a acoperi un set mai larg de documentații de proiectare (conform listei de mai sus) ^[15]și a fost considerat util în multe contexte. ^[16]

Metode de dezvoltare software[modificare sursă | modificare]

UML nu este o metodă de dezvoltare de sine stătătoare; cu toate ^[17]acestea, a fost concepută pentru a fi compatibilă cu principalele metode de dezvoltare de software orientate pe obiecte ale vremii sale (de exemplu, OMT, metoda Booch, Objectory) și în special cu RUP, pe care a fost inițial destinată să fie utilizată atunci când au început lucrările la Rational Software Inc.

Modelare[modificare sursă | modificare]

Este important să se facă distincția între modelul UML și setul de diagrame ale unui sistem. O diagramă este o reprezentare grafică parțială a modelului unui sistem. Nu este necesar ca setul de diagrame să acopere complet modelul, iar ștergerea unei diagrame nu modifică modelul. Modelul poate conține, de asemenea, documentație care conduce elementele modelului și diagramele (cum ar fi cazurile de utilizare scrise).

Diagramele UML reprezintă două viziuni diferite ale unui model^[18] de sistem:

• Viziunea statică (sau structurală): pune accentul pe structura statică a sistemului folosind obiecte, atribute, operații și relații. Viziunea structurală include diagrame de clasăși diagrame de structură compozită.
• Vizualizare dinamică (sau comportamentală): pune accentul pe comportamentul dinamic al sistemului prin prezentarea colaborărilor dintre obiecte și a modificărilor stărilor interne ale obiectelor. Această vedere include diagrame de secvență, diagrame de activitate și diagrame de mașini de stare.

Modelele UML pot fi schimbate între instrumentele UML prin utilizarea formatului de schimb de metadate XML (XMI).

UML 2 are mai multe tipuri de diagrame care sunt împărțite în două categorii.^[5] Unele tipuri reprezintă informații structurale, iar restul reprezintă tipuri generale de comportament, inclusiv câteva care reprezintă diferite aspecte ale interacțiunilor. Aceste diagrame pot fi clasificate ierarhic, așa cum se arată în următoarea diagramă^[5] de clasă:

Toate aceste diagrame pot conține comentarii sau note care să explice utilizarea, constrângerile sau intenția.

Diagrame de structură[modificare sursă | modificare]

Diagramele de structură pun accentul pe lucrurile care trebuie să fie prezente în sistemul modelat. Deoarece diagramele de structură reprezintă structura, acestea sunt utilizate pe scară largă în documentarea arhitecturii software a sistemelor software. De exemplu, diagrama de componente care descrie modul în care un sistem software este împărțit în componente și arată dependențele dintre aceste componente.

• Diagrama componentelor
• Diagrama de clasă

Diagrame de comportament[modificare sursă | modificare]

Diagramele de comportament pun accentul pe ceea ce trebuie să se întâmple în sistemul modelat. Deoarece diagramele de comportament ilustrează comportamentul unui sistem, acestea sunt utilizate pe scară largă pentru a descrie funcționalitatea sistemelor software. Ca exemplu, diagrama de activitate descrie activitățile operaționale și de afaceri pas cu pas ale componentelor unui sistem.

• Diagrama de activitate
• Diagrama cazului de utilizare

Diagrame de interacțiune[modificare sursă | modificare]

Diagramele de interacțiune, un subansamblu al diagramelor de comportament, pun accentul pe fluxul de control și de date între elementele din sistemul modelat. De exemplu, diagrama de secvență care arată modul în care obiectele comunică între ele prin intermediul unei secvențe de mesaje.

• Diagrama de secvență
• Diagrama de comunicare

Articol principal: Facilitatea Meta-Object

Ilustrație a mecanismului Meta-Object

Grupul de gestionare a obiectelor (OMG) a dezvoltat o arhitectură de metamodelare pentru a defini limbajul de modelare unificat (UML), numită Meta-Object Facility (MOF).^[19] Meta-Object Facility este concepută ca o arhitectură cu patru straturi, așa cum se arată în imaginea din dreapta. Acesta oferă un model meta-meta la nivelul superior, numit nivelul M3. Acest model M3 este limbajul utilizat de Meta-Object Facility pentru a construi metamodele, denumite modele M2.

Cel mai proeminent exemplu de model de nivel 2 Meta-Object Facility este metamodelul UML, modelul care descrie UML însuși. Aceste modele M2 descriu elemente ale stratului M1 și, prin urmare, modelele M1. Acestea ar fi, de exemplu, modelele scrise în UML. Ultimul strat este stratul M0 sau stratul de date. Acesta este utilizat pentru a descrie instanțele de execuție ale sistemului. ^[20]

Meta-modelul poate fi extins cu ajutorul unui mecanism numit stereotipare. Brian Henderson-Sellers și Cesar Gonzalez-Perez au criticat acest mecanism, considerându-l insuficient/nesustenabil, în "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". ^[21]

UML s-a dovedit a fi utilă în multe contexte de proiectare,^[16] atât de mult încât a devenit aproape omniprezentă în cadrul comunității IT. ^[22]

A fost tratată, uneori, ca un glonț de argint în materie de proiectare, ceea ce a dus la probleme în utilizarea sa. Utilizarea sa greșită include utilizarea excesivă a acestuia (proiectarea fiecărei mici părți a codului sistemului cu el, ceea ce nu este necesar) și presupunerea că oricine poate proiecta orice cu el (chiar și cei care nu au programat). ^[23]

Acesta este considerat un limbaj mare, cu multe construcții în el. Unii (inclusiv Jacobson) consideră că sunt prea multe și că acest lucru îngreunează învățarea (și, prin urmare, utilizarea) acestuia. ^[24]

Criticile comune ale UML din partea industriei includ: ^[4]

• nu este util: "[nu] le oferă avantaje față de practicile și reprezentările lor actuale, evoluate"
• prea complexe, în special pentru comunicarea cu clienții: "inutil de complex" și "Cel mai bun motiv pentru a nu utiliza UML este că nu este "lizibil" pentru toate părțile interesate. Cât valorează UML dacă un utilizator de afaceri (clientul) nu poate înțelege rezultatul efortului dumneavoastră de modelare?".
• necesitatea de a menține sincronizarea între UML și cod, ca și în cazul documentației în general

Critica lui UML 1.x[modificare sursă | modificare]

Noțiunea de cardinalitate

La fel ca în cazul bazelor de date Chen, Bachman și al diagramelor ISO ER, modelele de clasă sunt specificate pentru a utiliza cardinalități "look-across", chiar dacă mai mulți autori (Merise, ^[25]Elmasri & Navathe^[26], printre alții^[27]) preferă same-side sau "look-here" pentru roluri și cardinalități minime și maxime. Cercetători recenți (Feinerer, ^[28]Dullea, printre alții^[29]) au arătat că tehnica "look-across" utilizată de diagramele UML și ER este mai puțin eficientă și mai puțin coerentă atunci când este aplicată relațiilor n-ariante de ordin >2.

Feinerer spune: "Problemele apar dacă operăm în baza semanticii "look-across", așa cum este folosită pentru asociațiile UML. Hartmann^[30] investighează această situație și arată cum și de ce diferite transformări eșuează." (Deși "reducerea" menționată este falsă, deoarece cele două diagrame 3.4 și 3.5 sunt de fapt aceleași) și, de asemenea, "După cum vom vedea în paginile următoare, interpretarea look-across introduce mai multe dificultăți care împiedică extinderea mecanismelor simple de la asociațiile binare la cele n-ari."