UML1. Aparitie si evolutie

UML este un limbaj vizual de modelare.El nu este încă un limbaj vizual de programare,deoarece nu dispune de întreg sprijinul semantic şi vizual pentru a înlocui limbajele deprogramare. Limbajul este destinat vizualizării, specificării, construirii şi documentăriisistemelor de aplicaţii, dar are limitări în ceea ce priveşte generarea codului. UML reuneştecele mai bune tehnici şi practici din domeniul ingineriei programării, care şi-au dovediteficienţa în construirea sistemelor complexe.

UML este un element fundamental pentru Model-Driven Architecture ®, care reprezinta legaturile dintre mediul de afaceri si mediul de programare, prin modelarea arhitecturala şi aplicarea lor in dezvoltare, implementare, întreţinere şi evoluţie.

2. Principalele părţi ale UML

Principalele parti ale UML sunt: Vederile (View) – surprind aspecte particulare ale sistemului de modelat. Un view este o

abstractizare a sistemului, iar pentru construirea lui se folosesc un număr de diagrame.

Diagramele – sunt grafuri care descriu conţinutul unui view. UML are nouă tipuri de diagrame, care pot fi combinate pentru a forma toate view-urile sistemului.

Elementele de modelare – sunt conceptele folosite în diagrame care au corespondenţă în programarea orientată-obiect, cum ar fi: clase, obiecte, mesaje şi relaţii între acestea: asocierea, dependenţa, generalizarea. Un element de modelare poate fi folosit în mai multe diagrame diferite şi va avea acelaşi înteles şi acelaşi mod de reprezentare.

Mecanismele generale – permit introducerea de comentarii şi alte informaţii despre un anumit element.

2.1 View-uri

Modelarea unui sistem poate fi o muncă foarte dificilă. Ideal ar fi ca pentru descriereasistemului să se folosească un singur graf, însă de cele mai multe ori acesta nu poate săsurprindă toate informaţiile necesare descrierii sistemului. Un sistem poate fi descris luând înconsiderare diferite aspecte:

Funcţional: este descrisă structura statică şi comportamentul dinamic al sistemului; Non-funcţional: necesarul de timp pentru dezvoltarea sistemului Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod;

Aşadar pentru descrierea unui sistem sunt necesare un număr de view-uri, fiecarereprezentând o proiecţie a descrierii intregului sistem şi care reflectă un anumuit aspect al sau.Fiecare view este descris folosind un număr de diagrame care conţin informaţii relativela un anumit aspect particular al sistemului. Aceste view-uri se acoperă unele pe altele, decieste posibil ca o anumită diagramă să facă parte din mai multe view-uri.

1

Figura 1 View-urile din UML.

View-ul cazurilor de utilizare (Use-case View)Acest view surprinde funcţionalitatea sistemului, aşa cum este ea percepută de actoriiexterni care interacţionează cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme. Cei interesaţi de acest view sunt deopotrivă clienţii, designerii, dezvoltatorii dar şi ceicare vor realiza testarea şi validarea sistemului.

View-ul logic (Logic View)Spre deosebire de view-ul cazurilor de utilizare, un view logic “priveşte” înăuntrulsistemului şi descrie atât structura internă a acestuia (clase, obiecte şi relaţii) cât şicolaborările care apar când obiectele trimit unul altuia mesaje pentru a realiza funcţionalitateadorită.Structura statică este descrisă în diagrame de clasă, în timp ce pentru modelareadinamicii sistemului se vor folosi diagramele de stare, de secventă, de colaborare sau deactivitate. Prin urmare, cei care sunt interesaţi de acest tip de vizualizare a sistemului suntdesignerii şi dezvoltatorii.

View-ul componentelor (Component View)Componentele sunt module de cod de diferite tipuri. În funcţie de conţinutul lor acesteapot fi: componente care conţin cod sursă, componente binare sau excutabile.View-ul componentelor are rolul de a descrie componentele implementate de sistem şidependenţele ce există între ele, precum şi resursele alocate acestora şi eventual alteinformaţii administrative, cum ar fi de exemplu un desfaşurător al muncii de dezvoltare. Estefolosit în special de dezvoltatorii sistemului, iar în componenţa sa intră diagrame alecomponentelor.

View-ul de concurenţă (Concurent View)Sistemul poate fi construit astfel încât să ruleze pe mai multe procesoare. Acest aspect,

2

care este unul nonfuncţional, este util pentru o gestionare eficientă a resurselor, execuţiiparalele şi tratări asincrone ale unor evenimente din sistem, precum şi pentru rezolvarea unorprobleme legate de comunicarea şi sincronizarea theadu-urilor.Cei care sunt interesaţi de o astfel de vizualizare a sistemului sunt dezvoltatorii şiintegratorii de sistem, iar pentru construirea lui se folosesc diagrame dinamice (stare,secventă, colaborare şi activitate) şi diagrame de implementare (ale componentelor sau dedesfăşurare).

View-ul de desfăsurare (Deployment View)Desfăşurarea fizică a sistemului, ce calculatoare şi ce device-uri (numite şi noduri) vorfi folosite pentru realizarea efectivă a implementării, cum sunt acestea conectate, precum şi cecomponente se vor executa pe fiecare nod (de exemplu ce program sau obiect este executat pefiecare calculator), toate sunt surprinse în view-ul de desfăşurare.Aceast tip de vizualizare a sistemului prezintă interes sunt dezvoltatori, integratorii desistem şi cei care realizează testarea sistemului, iar pentru construirea view-ului este folositădiagrama de desfăşurare.

2.2 Diagrame

Diagramele sunt grafuri care prezintă simboluri ale elementelor de modelare aranjate astfel încât să ilustreze o anumită parte sau un anumit aspect al sistemului. Un model are de obicei mai multe diagrame de acelaşi tip. O diagramă este o parte a unui view specific, dar există posibilitatea ca o diagramă să facă parte din mai multe view-uri, în funcţie de conţinutul ei. În UML sunt nouă tipuri de diagrame pe care le vom prezenta în cele ce urmează.

Diagrama cazurilor de utilizare (Use Case Diagram)Descrie modul de functionare al aplicatiei. Diagrama prezintă actorii externi (ex. client, server) , cazurile de utilizare identificate precum şi conexiunile dintre actori. Nu descrie modul interior de functionare al aplicatiei. Un exemplu de diagramă a cazurilor deutilizare este prezentată în figura 2.

3

Figura 2 O diagrama a cazurilor de utilizare dintr-un sistem de asigurari.

Diagrama claselor (Class Diagram)O diagramă a claselor prezintă structura fizică a claselor identificate în sistem. Claselereprezintă “obiecte” gestionate de sistem; clasele pot fi legate în mai multe moduri: asociate (conectate între ele), dependente (o clasa depinde/foloseşte o altă clasă), specializate (o clasăeste specializarea altei clase) sau împachetate (grupate împreună în cadrul unei unitaţi). Toateaceste relaţii se materializează în structura internă a claselor în atribute şi operaţii.

Diagrama este considerată statică, în sensul că este validă în orice moment din ciclul deviaţă al aplicatiei. Un exemplu de diagramă a claselor este prezentat în figura 3.

4

Figura 3 Diagrama claselor.

Diagrama obiectelor (Object Diagram)Acest tip de diagramă este o varianta a diagramei claselor care în locul unei claseprezintă mai multe instanţe ale ei. Diagrama obiectelor foloseşte aproape aceleaşi notaţii ca şidiagrama claselor cu două mici diferenţe: obiectele sunt scrise subliniat şi sunt vizualizatetoate instantele relaţiei (vezi figura 4).Deşi nu este la fel de importantă ca diagrama claselor, cea o obiectelor este folosităpentru exemplificarea unei diagrame a claselor de complexitate mare, permiţând vizualizariale instanţelor actuale şi a relaţiilor exact aşa cum sunt ele realizate. Mai poate fi folosită ca oparte a diagramelor de colaborare, în care sunt vizualizate colaborările dinamice existente încadrul unui set de obiecte.

5

Figura 4 O diagrama a claselor si o diagrama a obiectelor (instantele claselor).

Diagrama de stare (State Diagram)O stare este de obicei un complement al descrierii unei clase. O diagramă de stareprezintă toate stările prin care trece un obiect al clasei precum şi evenimentele care-i cauzeazămodificările de stare. Modificarea stării se numeşte tranziţie. Un exemplu de diagramă destare este prezentat în figura 5.

6

Figura 5 O diagrama de stare pentru un ascensor.

Nu vom construi diagrame de stare pentru toate clasele din sistem ci numai pentruacelea care au un număr de stări bine definit iar comportamentul clasei este afectat şimodificat de acestea.

Diagrama de secvenţă (Sequence Diagram)O diagramă de secvenţă prezintă colaborarea dinamică între un număr de obiecte (vezifigura 6), mai precis secvenţele de mesaje trimise între acestea pe măsura scurgerii timpului.Obiectele sunt văzute ca linii verticale distribuite pe orizontală, iar timpul estereprezentat pe axa verticală de sus în jos. Mesajele sunt reprezentate prin săgeţi între linileverticale ce corespund obiectelor implicate în mesaj.

7

Figura 6 Diagrama de secventa pentru un server de imprimanta.

Diagrama de colaborare (Collaboration Diagram)Această diagramă surprinde colaborarea dinamică între obiecte, într-o manieră similarăcu a diagramei de secvenţă, dar pe lângă schimbul de mesaje (numit şi interacţiune) prezintăobiectele şi relaţiile dintre ele (câteodată referite ca şi context).

Cum decidem ce tip de diagramă să folosim? Dacă cel mai important aspect este timpulsau secvenţa de mesaje vom folosi diagrama de secvenţă, dar dacă trebuie scos în evidentăcontextul, vom apela la o diagramă de colaborare.Desenarea unei diagrame de colaborare se face similar cu a unei diagrame a obiectelor.Mesajele vor fi reprezentate prin săgeţi între obiectele implicate în mesaj şi pot fi însoţite deetichete care specifică ordinea în care acestea vor fi transmise. De asemenea se pot vizualizacondiţii, iteraţii, valori returnate, precum şi obiectele active care se execută concurent cu alteobiecte active (vezi figura 7).

8

Figura 7 O diagrama de colaborare pentru un server de imprimanta.

Diagrama de activitate (Activity Diagram)O diagramă de activitate prezintă fluxul secvenţelor de activitaţi, ca în figura 8, şi estede obicei folosită pentru a descrie activitaţile realizate în cadrul unei operaţii, folosind dacăeste cazul decizii şi condiţii.Diagrama conţine stări de acţiune (action states), şi mesaje care vor fi trimise saurecepţionate ca parte a acţiunii realizate.

Figura 8 O diagrama de activitate pentru un server de imprimanta.

Diagrama componentelor (Component Diagram)O diagramă a componentelor prezintă structura fizică a codului în termeniicomponentelor de cod, realizând o mapare de la view-ul logic la view-ul componentelor. Ocomponentă poate să conţină un cod sursă sau poate să fie într-o forma binară sau executabilă.În cadrul diagramei vor fi ilustrate şi dependenţele dintre componente, ceea ce permite ovizualizare simplă a componentelor care vor fi afectate de modificarea uneia dintre ele.

9

Figura 9 O diagrama a componentelor.

Diagrama de desfăşurare (Deployment View)Arhitectura fizică pe care va fi implementat sistemul, calculatoarele, device-urile(referite ca nodurile sistemului), împreună cu conexiunile dintre ele, vor putea fi prezentate încadrul unei diagrame de desfaşurare. Componentele şi obiectele executabile sunt alocate îninteriorul nodurilor, ceea ce ne va permite o vizualizare a unitaţilor care se vor executa pefiecare nod.

10

Figura 10 O diagrama de desfasurare care prezinta structura fizica a sistemului.

3. Versiuni UML

Versiunea Data Aparitiei Descriere

1.4 09-2001Cea mai importanta schimbare adusa de UML 1.4 consta in adaugarea profilurilor, ceea ce permite colectarea unui grup de extensii intr-un ansmblu coherent. Documentatia UML contine doua exemple de profiluri. Totdata , formalismul definirii de stereotipuri a crescut si elementele modelului au putut avea mai multe stereotipuri, in timp ce in UML 1.3 exista unul singur.

S-a lucrat asupra vizibilitatii pachetelor Java in metamodele si asupra marcarii asincronismelor prin sageti in diagrame de secventa.

2.0 08-2005Una din cele mai importante schimbari este cea legata de tipurile de diagrame. Diagramele de obiecte si diagramele de pachete devin diagrame oficiale. Diagramele de colaborare devin diagrame de comunicare. In aceasta versiune sunt introduce, de asemenea, noi tip de asamblu a interactiunilor, timing si structuri composite.

Atributurile si asocierile unidirectionare devin doua notatii esential diferite pentru a reprezenta conceptul sub-adiacent de proprietate. S-au adaugat noi cuvinte cheie pentru dependente. Cuvintele cheie <<parameter>> si <<local>> nu se mai utilizeaza.

Diagrame de secventa:

Modificarea cea mai importanta este notatia cadrelor de interactiune, care permite gestionarea structurilor interative, conditionale si a altor structuri de control a comportamentului. Puteti exprima aproape in intregime algoritmii in diagramele de secventa. Vechile marcaje de iteratii si notatiile lor au fost abandonate. Antetele de linii de viata nu mai sunt instante, acestea fiind definite prin termenul participant. Diagramele de colaborare se numesc acum diagrame de comunicare.

Referitor la diagramele de clase: concept avansate

Stereotipurile sunt definite de o maniera mai stricta. In consecinta, exista cuvinte cheie pentru a define expresiile intre ghilimele, numai unele dintre acestea din urma fiind stereotipuri. In diagramele de obiecte, instantele sunt acum specificatii de instante. Clasele pot solicita interfete si le pot realiza. Clasificarea multipla utilizeaza ansamblu de generalizare pentru a regrupa generalizarile. Componentele nu mai sunt reprezentate printr-un simbol special. Obiectele active au linii duble vertrical in loc de linii groase.

11

Diagramele de stare

Daca UML 1 facea distinctia intre actiuni si activitati, UML 2 numeste cele doua activitati si utilizeaza acest termen in toate cazurile.

Diagramele de activitati

UML 1 trata diagramele de activitati ca pe un caz particular al diagramelor de stare. UML 2 a rupt legatura intre acestea si a suprimat regulile de corespondenta a ramificatiilor si jonctiunilor pe care le instaurase UML 1. Au aparut noi notatii, printre care acelea de semnale temporare si de acceptare, paramatri, specificatii de jonctiune, conectori, transformatori de fluxuri, greble de sub-diagrame, regiuni de expansiune si terminatii de fluxuri. UML 1 considera mai multe fluxuri de intrare intr-o activitate ca pe o fuziune implicita, in timp ce UML 2 le trateaza ca pe o jonctiuni implicita. Pentru a evita confuziile, recomandam utilizarea fuziunilor si jonctiunile explicite in diagramele de activitati.

2.1 04-2006 Modificari minore fata de versiunea UML 2.0 - corecţii şi îmbunătăţiri de consistenţă.

2.1.1 02-2007 Modificari minore fata de versiunea UML 2.1

2.1.2 11-2007 Modificari minore fata de versiunea UML 2.1.1

2.2 02-2009 Imbunatatirea aduse numeroaselor probleme de consistenta si adaugarea unor clarificari la UML 2.1.26

4. Tool-uri pentru generarea diagramelor UML

Exista mai multe tipuri de programe utilizate.

In functie de tipul licentei acestea se impart in :

Freeware (soft gratuit) - care sunt puse la dispozitia tuturor utilizatorilor. Ex.: StarUML, UMLet, ArgoUML .

Commercialware (contra cost) – profesionale, prezinta un set mai mare de optiuni pentru realizarea diagramelor. Ex.: Altova Umodel, Edraw UML Diagram.

In functie de interactiunea cu IDE (Integrated Development Environment)

Independente de IDE. Ex.: Altova Umodel, StarUML.

12

Altova Umodel - > OS: Microsoft Windows

- > v. 2011 Service Pack 1 (SP1)

StarUML - > OS: Microsoft Windows

- > v.5.0, 30 Decembrie 2005

Pluginuri pentru IDE. Ex.: MaintainJ Plugin, SDE IntelliJ IDEA.

MaintainJ Plugin -> OS: Cross-platform

- > IDE: min. Eclipse 3.2

- > v 2.9, 29 Martie 2010

SDE IntelliJ IDEA - > OS: Cross-platform

- > IDE: min. Intelli JIDEA 9

- > v 4.0, 16 Octombrie 2010

Ultima vesiune de UML este 2.3.

4.1 Instalarea unui plugin in Eclipse

Pasi necesari:

1. Programele necesare pentru instalarea plugin-ului sunt disponibile pe site-ul http://www.eclipse.org/modeling/mdt/downloads/?project=uml2tools. Prima data se instaleaza programele din categoria Build Dependencies, ulterior cele din sectiunea UML2 Tools.

13

2. Din interiorul programului Eclipse se selecteaza categoria Help->Install new software. In noua fereastra care se va deschide vom introduce cuvantul cheie “model” pentru a gasi toate plugin-urile necesare modelarii diagramelor UML. Se vor selecta toate plugin-urile mentionate in pasul anterior.

14

3. Dupa instalarea plugin-urilor, diagramele UML se pot crea prin selectarea meniului File->New->Other->UML 2.1 Diagrams->Class Diagram.

15

4. In continuare vom selecta proiectul a carui diagram o vom realiza.

5. Selectam noul fisier .uml creat. Din cadrul sectiunii palette vom selecta tipul de element pe care dorim sa il cream: clase, interfete, variabile, etc.

16

6. In continuare se pot realiza diagramele dorite cu ajutorul elemetelor puse la dispozitie de meniul “Palette”.

4.2 Generare diagrame utilizand aplicatia Altova Umodel 2009

Pasi necesari:

17

1. Descarcarea (contra cost) si instalarea aplicatie de pe sit-ul producatorului: http://www.altova.com/download/umodel/uml_tool_enterprise.html

2. Creeare proiect nou utilizand optiunea File -> New din meniu

18

3. Importarea fisierelor ce contin codul aplicatiei dupa care se vor genera diagramele. (utilizand meniul Project -> Import Binary Tipes )

Se adauga fisierele necesare.

19

4. Dupa adaugarea fisierelor din fereastra Model Tree se pot genera diagramele dorite. (click dreapta pe numele pachetului ce contine fisierele aplicatiei -> Show in new diagram -> content).

20

Selctarea tipului de diagrama dorit.

21

22

5. Exemplu de diagrame generate:

-Diagrama de clase

23

-Analog in cazul in care aplicatia are mai multe pachete (diagrama de pachete).

5. Diagrame statice vs. Dinamice

Diagrame statice: Prezinta structura statica a unui model, cu alte cuvinte elementele care exista (clasele, atributele, metodele, etc.), structura interna a elementelor si relatiile dintre ele. Sunt utilizate pentru a creea diagrame care reprezinta concepte din lumea reala si relatiile dintre ele sau diagrame de clase care descompun un sistem software in partile sale componente.

24

Diagrame dinamice: Sunt diagrame realizate la un moment dat in timpul rularii unui program. Acestea descriu obiectele active la un moment dat si relatiile dintre ele si difera in functie de momentul in care este surprins programul in timpul rularii (Ex. diagrame de secventa, diagrame de stare, diagrame de activitate).

6. Notatii UML:

Figura 11 Reprezentarea grafică în UML a unei agregări partajate

Figura 12 Reprezentarea grafică în UML a unei compoziţii

Figura 13 Reprezentarea grafică în UML a unei tranziţii

25

Figura 14 Reprezentarea grafică în UML a unei dependenţe

Figura 15 Reprezentarea grafică în UML a unei relaţii de derivare

Figura 16 Reprezentarea grafică în UML a unei relaţii de extensie

Figura 17 Reprezentarea grafică în UML a unei relaţii de realizare

Figura 18 Simbolul folosit în UML pentru reprezentarea interfeţelor

Figura 19 Simbolul folosit in UML pentru reprezentarea interfetelor

Figura 20 Simbolul folosit în UML pentru reprezentarea claselor

26