Crearea şi editarea de diagrame UML

1. Obiectul lucrării

UML este un limbaj pentru specificarea, vizualizarea, construirea şi documentarea elementelor sistemelor software, fiind un standard pentru modelarea software. Obiectivele acestei lucrări sunt prezentarea unor tipuri de diagrame UML şi introducerea aplicaţiei de creare/editare a diagramelor UML.

2. Introducere teoretică

UML (Unified Modeling Language) este un limbaj pentru modelare util în domeniul software la realizarea documentelor de specificaţii; în general, bun pentru comunicarea între ingineri. Faza de analiză şi concepţie a unui proiect trebuie să fie gata înainte de realizarea codului, pentru a obţine o atenţie sporită din partea diverşilor dezvoltatori. Aceste etape au fost ignorate în trecut, dar în prezent orice dezvoltator recunoaşte importanţa acestor faze deoarece s-a dovedit că de acestea depinde producerea şi refolosirea de software. Pentru analiza şi proiectarea programelor s-au creat limbajele de modelare. Unul dintre aceste limbaje de modelare este limbajul de modelare unificat, UML (Unified Modeling Language).

UML nu este un simplu limbaj de modelare orientat pe obiecte, ci în prezent este limbajul universal standard pentru dezvoltatorii software din toată lumea. UML este succesorul propriu-zis al celor mai bune trei limbaje anterioare de modelare orientate pe obiecte (Booch, OMT şi OOSE). UML se constituie din unirea acestor limbaje de modelare şi în plus deţine o expresivitate care ajută la rezolvarea problemelor de modelare pe care vechile limbaje nu o aveau.

UML oferă arhitecturi de sisteme care funcţionează pe analiza şi proiectarea obiectelor cu un limbaj corespunzător pentru specificarea, vizualizarea, construirea şi documentarea artefactelor sistemelor software şi, de asemenea, pentru modelarea în întreprinderi. UML este un limbaj de modelare care oferă o exprimare grafică a structurii şi comportamentului software. Pentru aceasta exprimare grafică se utilizează notaţiile UML.

Notaţiile UML constituie un element esenţial al limbajului pentru realizarea propriu-zisă a modelării, şi anume, partea reprezentării grafice pe care se bazează orice limbaj de modelare. Modelarea în acest limbaj se realizează prin combinarea notaţiilor UML în cadrul elementelor principale ale acestora, denumite diagrame.

În cadrul UML-ului există 9 tipuri de diagrame:

1. diagrama cazurilor de utilizare,

2. diagrama de secvenţă,

3. diagrama de colaborare,

4. diagrama de clase (cea mai utilizată),

5. diagrama de stări,

6. diagrama de componente,

7. diagrama de construcţie,

8. diagrama de obiecte,

9. diagrama de activităţi.

3. Descrierea aplicaţiei

Tehnologia de bază a aplicaţiei este Javascript, şi anume, librăria jsuml, creată de către Rafael Molina-Linares, Martin Vega-Leal şi José-Raúl Romero. Această librărie are o arhitectură bazată pe niveluri. Gestionarea graficii, obiecte specifice diagramelor UML, se realizează folosind obiectele aplicaţiei, care sunt separate în diverse fişiere. Astfel, librăria are două fişiere de bază:

· UDCod. Reprezintă nucleul librăriei şi se concentrează asupra funcţionalităţilor de bază, precum trasarea de linii şi forme, gestionarea evenimentelor produse de utilizator.

· UDModules. Este nivelul care conţine obiectele UML.

Interfaţa iniţială a aplicaţiei se poate vizualiza în figura 1.

Fig. 1. Interfaţa iniţială a aplicaţiei.

În partea stânga sunt afişate acţiunile disponibile, cât şi elementele specifice fiecărui tip de diagramă. Aceste elemente apar în momentul în care a fost selectată o diagramă sau o zonă de lucru. Acţiunile disponibile se pot observa în figura 2.

Fig. 2. Meniul principal al aplicaţiei.

În continuare, se vor descrie acţiunile în ordinea apariţiei lor în meniu. Aşadar, prima acţiune care se observă este cea de export/import de XML sau deschidere/salvare Diagramă. La apăsarea butonului va apărea o nouă fereastră cu meniul prezentat în figura 3.

Fig. 3. Meniul de export/import şi deschidere/salvare de diagrame.

Acţiunea de export transformă toate elementele din canvas („pânza” pe care se creează obiectele/diagramele) în documente de tip XML. Importul efectuează acţiunea opusă celei de export şi generează diagrame UML pe baza unei scheme XML.

Pentru a se punea salva zona de lucru în baza de date (MySQL), mai întâi trebuie să fie apăsat butonul de export, după care se va deschide o fereastră în care se poate introduce un nume şi/sau se poate salva sub un nume deja aflat în baza de date.

Introducerea în baza de date se face folosind Ajax, care trimite către fişierul PHP (save.php) numele zonei de lucru, cât şi conţinutul acesteia, conţinut care este format dintr-un XML. Zona de lucru poate conţine una sau mai multe diagrame.

Pentru a deschide o zonă de lucru se afişează o fereastră de unde se poate selecta zona de lucru dorită. Această acţiune se face prin crearea unei cereri Ajax către server, care va returna un răspuns conţinând un XML. XML-ul este copiat în zona de conţinut text şi se activează evenimentul de clic asupra butonul import.

Acţiunea „Salvează poza” are rolul de a exporta/salva diagrama curent deschisă cu ajutorul funcţiei Javascript toDataURL. Această funcţie este relativ nouă în Javascript, fiind introdusă odată cu apariţia standardului HTML5, şi citeşte toată informaţia din interiorul canvas-ului (pânzei de lucru), codând-o în baza 64.

Butonul Schimbă culoare afişează o fereastră (imaginea din figura 3) formată din 3 dreptunghiuri RGB (Red, Green, Blue), de unde se poate efectua câte un clic asupra acestora, creând o nouă nuanţă din combinarea celor 3 tipuri de culori.

Fig. 3. Alegerea unei culori pentru un element din zona de lucru.

După ce a fost selectată culoarea dorită, se apasă butonul Ok, iar elementele UML care se vor aplica vor avea culoarea de fundal selectată anterior (vezi figura 4).

Fig. 4. Elementul „Clasă” colorat în albastru.

Pentru a şterge un element sau o legătură dintre elementele din diagramă se utilizează acţiunea „Şterge Obiect”. Aceasta se desfăşoară în două etape:

1. Se efectuează clic pe acţiunea „Şterge Obiect”;

2. Se efectuează clic pe obiectul/legătura din diagrama deschisă.

Dacă este şters un obiect din diagramă, toate legăturile care vin înspre sau pleacă dinspre acel obiect sunt şterse. După ce un obiect sau o legătură este şters/ştearsă, aplicaţia redesenează (randează) obiectele din canvas, exact aşa cum erau înainte de a fi şters un obiect, mai puţin cel şters.

Diagrama nouă (de tip: clasă, cazuri de utilizare, stare) generează o nouă zonă de lucru atunci când asupra ei se efectuează un clic, elementele specifice diagramei selectate apărând în zona destinată acestora.

După ce a fost selectată o diagramă, elementele specifice acelei diagrame apar în zona destinată acestora. Aceste elemente sunt de două tipuri:

· obiectele specifice diagramei,

· legăturile dintre obiecte.

3.1. Diagramele de tip clasă

În UML, termenul de componentă desemnează un element software din componenţa fizică a unui sistem. Astfel, o componentă poate fi: cod binar, document, fişier conţinând cod sursă sau date, tabelă a unei baze de date etc. O componentă binară este o parte fizică şi substituibilă a unui sistem, care realizează o funcţie şi este în conformitate cu un set de interfeţe.

În figura 5 se poate observa un exemplu de utilizare a un obiect „componentă”. Între obiectele de acest gen există o legătură de „dependenţă”. Clasele sunt reprezentate prin dreptunghiuri împărţite în trei compartimente şi care conţin numele clasei (în compartimentul superior), lista de atribute ale clasei (opţional) şi lista de operaţii (opţional) cu argumentele lor şi tipul returnat.

Fig. 5. Exemplu de clasă care poartă numele „Maşina”, are 3 atribute şi 3 metode.

Regulile de vizibilitate se aplică atât atributelor cât şi operaţiilor din clase şi se referă la domeniul de acces permis unui membru al unei clase. Fiecare nivel de vizibilitate este reprezentat printr-un simbol:

· Private (-) : accesibilitate numai din interiorul clasei;

· Public (+) : accesibilitate la nivelul întregului sistem;

· Protected (#) : accesibilitate în arborele de moştenire;

· Package (~) : accesibilitate din interiorul pachetului care conţine acea clasă.

Asocierea poate avea sau nu un nume care se va afla tipărit în vecinătatea sa şi va conţine o săgeată precizând modul de citire al acestuia. O asociere poate avea nume diferite pentru fiecare direcţie. Fiecare capăt al asocierii este un rol şi fiecare rol poate avea un nume (nume de rol), care arată cum este văzută clasa asociată lui de către o alta.

Fiecare rol indică multiplicitatea clasei sale (câte instanţe ale clasei pot fi asociate cu o instanţă a altei clase). Multiplicitatea poate fi 1 (nu se marchează), 0-1 (marcată printr-un cerc alb) 0 sau mai multe (marcată printr-un cerc negru) sau alte intervale de valori întregi care se indica prin expresii de tipul 1+ (mai mult de o instanţă), 3 (exact trei instanţe) sau 2-4 (între 2 şi 4 instanţe inclusiv).

Fig. 6. Exemplificarea multiplicităţii pentru 3 clase.

Agregarea este o formă particulară de asociere care exprimă o relaţie „compus-componenţi". O clasă are anumite părţi, care însă au o existenţă independentă. Agregarea este desemnată printr-un un mic romb amplasat alături de clasa agregat.

Fig. 7. Exemplificarea agregării pentru două clase.

Compunerea este un caz particular de agregare, care exprimă o agregare prin conţinere fizică.

Fig. 8. Exemplificarea agregării pe un caz particular.

Reprezentarea relaţiei maşină-motor ca relaţie de compunere face ca fiecare maşină să aibă un motor unic, care nu poate fi înlocuit, iar motorul nu poate fi pus în altă maşină. Generalizarea constă în factorizarea elementelor comune (atribute, operaţii şi constrângeri) ale unui ansamblu de clase într-o clasă mai generală, numită superclasă. Clasele sunt ordonate într-o ierarhie.

Fig. 9. Exemplu de generalizare a unei clase.

Între pachete pot exista următoarele relaţii:

· Import/export. Presupunând două pachete, A şi B, dacă pachetul A importă pachetul B, atunci elementele din A vor vedea elementele publice din B. Partea publică a lui B reprezintă exportul pachetului B. Grafic, se reprezintă printr-o relaţie de dependenţa stereotipizată <<import>>.

Fig. 10. Importul unui pachet.

· Generalizare. Este asemănătoare generalizării claselor. Pachetele mai specializate moştenesc elementele publice şi protejate de la pachetul mai general. La fel ca în cazul claselor, pachetele mai specializate pot înlocui pachetele mai generale, oriunde sunt folosite acestea.

Fig. 11. Generalizarea unui pachet.

Interfaţa reprezintă o colecţie de operaţii care specifică un serviciu al unei clase sau al unei componente.

Fig. 12. Exemplu de folosire a unei interfeţe.

3.2. Diagramele de tip cazuri de utilizare

Cazul de utilizare implică interacţiunile dintre actori şi sistem. Actorii pot fi oameni sau sisteme automate. Grafic, un caz de utilizare se reprezintă printr-o elipsă. Fiecare caz de utilizare trebuie să aibă un nume distinct de al celorlalte cazuri de utilizare. Numele este format dintr-un şir de caractere şi se numeşte „nume simplu”. „Nume de cale” este numele cazului de utilizare prefixat de numele pachetului din care face parte acesta.

Actorul reprezintă un set de roluri pe care utilizatorul le foloseşte când interacţionează cu cazurile de utilizare. Un actor reprezintă un rol uman, un dispozitiv hardware sau orice alt sistem. O instanţă a unui actor reprezintă o interacţiune individuală cu sistemul. Actorii nu fac parte din sistem. Ei se află în afara sistemului şi pot fi conectaţi la cazuri de utilizare prin asocieri.

Comportamentul unui caz de utilizare se poate specifica prin descrierea fluxului de evenimente. Când se scrie fluxul de evenimente, trebuie să se indice cum şi când începe şi se încheie cazul de utilizare, când interacţionează cu actorii, ce obiecte sunt schimbate, fluxul de bază şi variantele comportamentului.

Fig. 13. Exemplu al unei diagrame UML de tip cazuri de utilizare.

3.3. Diagramele de stare

O diagramă de stare modelează viaţa unui obiect prin stările sale şi schimbările de stare care au loc pe parcursul vieţii. Schimbările de stare sunt determinate de evenimente. Diagramele de stări modelează efectul acestor interacţiuni asupra stării interne a fiecărui obiect. Mesajele din diagramele de interacţiune sunt evenimente care schimbă starea internă a obiectelor. Examinând diagramele de interacţiune se pot descoperi care sunt obiectele care ar trebui modelate prin diagrame de stări. Multe obiecte sunt create, referite şi apoi distruse. Ele au o singură stare intermediară şi deci nu are sens modelarea lor printr-o diagramă de stări. Alte obiecte, însă, care răspund la mesaje în mod diferit pe parcursul vieţii, se pot preta la această modelare.

Stările sunt reprezentate prin dreptunghiuri rotunjite iar tranziţiile prin săgeţi deschise. Starea iniţială şi cea finală se reprezintă astfel:

starea iniţială starea finală

Fig. 14. Stările iniţială şi finală.

Starea iniţială identifică (punctează către) starea în care obiectul este creat. De exemplu, în figura 14 această stare este Create. Cu toate că notaţia pentru starea iniţială include numai cercul plin, în practică starea iniţială include şi săgeata care pleacă din ea şi starea în care obiectul este creat.

La sfârşitul vieţii (activităţii) sale, obiectul atinge starea finală, din care nu mai poate ieşi. Starea finală are toate proprietăţile unei stări, cu o excepţie: nu poate avea tranziţii de ieşire. Numele stării de ieşire este specificat lângă simbolul grafic al stării finale.

O simplă tranziţie reprezintă o relaţie între două stări consecutive, indicând faptul schimbării unei stări cu o alta. Prezenţa obiectului modelat în prima stare va efectua anumite acţiuni, dar trecerea în starea a doua se va produce atunci când anumite acţiuni vor fi terminate şi după îndeplinirea anumitor condiţii suplimentare.

Tranziţia începe atunci când un anumit eveniment se petrece: terminarea executării acţiunii (do activity), trimiterea mesajului sau emiterea semnalului. În trecere se indică numele acţiunii. Mai mult chiar, în tranziţie poate fi indicată acţiunea produsă de un obiect ca reacţia tranziţiei de la o stare la alta.

Executarea tranziţiei poate depinde nu numai de petrecerea unui anumit eveniment, dar şi de la îndeplinirea condiţiei corespunzătoare, care se numeşte condiţie gardă. Obiectul va trece de la o stare la alta, numai în cazul în care a apărut acţiunea indicată şi condiţia de gardă este îndeplinită.

Fig. 15. Exemplu al unei diagrame UML de stare.

Starea compusă (composite state) este o stare alcătuită din alte stări depuse. Ultimele vor fi substările (substate) pentru primul element. Deşi între ele există relaţia de compoziţie, grafic, toate vârfurile diagramei care corespund substărilor depuse sunt reprezentate înăuntrul simbolului stării compuse. În acest caz, dimensiunile simbolului grafic al stării compuse se măresc astfel ca toate substările să fie incluse.

Fig. 16. Exemplu de stare compusă.

4. Desfăşurarea lucrării

Se instalează aplicaţia wamp (de exemplu, în C:\wamp). După ce wamp-ul a fost instalat, se va face un import al dump-ului. Pentru a face acest lucru se deschide phpmyadmin, accesând URL-ul http://localhost/phpmyadmin. Aici se deschide tab-ul „Databases”, se introduce numele bazei de date (jsuml), se alege collation „utf8_general_ci” şi se apasă butonul „Create”.

Având baza de date creată, următorul pas îl constituie importul acesteia. În partea stângă a aplicaţiei phpmyadmin, se observă numele noii baze de date create. Se face clic pe acesta şi apoi pe butonul Import. De aici se va efectua upload-ul fişierului db.sql, făcând clic pe butonul Browse/Choose din dreptul propoziţiei „Browse your computer”. Se va selecta fişierul db.sql de pe hard-disk şi se va apăsa butonul „GO”. Se copiază directorul jsuml în C:\wamp.

Observaţie. Dacă numele bazei de date este altul decât jsuml, sau utilizatorul mysql root are o parolă, se pot modifica aceste date accesând fişierele open.php şi save.php. de unde se modifica doar cuvintele cu bold din următoarele linii:

$link = mysql_connect('localhost', 'root', 'password');

$db_selected = mysql_select_db('jsuml', $link);

unde:  localhost = numele serverului;

root = numele utilizatorului bazei de date;

password = parola asociată utilizatorului bazei de date,

jsuml = numele bazei de date.

Pentru a rula aplicaţia, se accesează URL-ul http://localhost/jsuml, folosind ca browser ultima versiune de Mozilla Firefox, Google Chrome sau Internet Explorer.

1. Se selectează diagrama nouă de tip clasă .

2. Numele diagramei curente se poate schimba făcând clic pe porţiunea de deasupra zonei de lucru . Noul nume va fi „Diagrama Calculator”.

3. Se introduce un pachet, astfel: se face clic pe elementul „Container pentru pachet (Package)” şi apoi încă un clic în zona de lucru în care se doreşte a fi poziţionat elementul. Numele pachetului astfel introdus va fi „ComponentePlacaBază”.

Observaţie: orice element poziţionat în zona de lucru poate fi redimensionat cu drag&drop deasupra pătratului din stânga jos a elementului .

4. Se ataşează pachetului un număr de 4 clase (Rezistor, Condensator, Tranzistor, Diodă). Acest lucru se face prin apăsarea elementului „Clasă”, modificarea numelui clasei şi adăugarea elementului de legătură „Alcătuieşte” pentru a face legătura dintre pachet şi clasă.

Observaţie: numele clasei se poate schimba făcând clic pe porţiunea din partea de sus a elementului (vezi figura 16).

Fig. 16. Elementele unei clase.

5. Se creează o nouă clasă „PlacaDeBază”, care are ca atribute publice atributele „Procesor” şi „PlacaVideo”. Clasa „PlacaDeBază” va importa pachetul denumit ComponentePlacaBază, folosind elementul „Import public de pachete”. Acest element se foloseşte ca şi elementul Alcătuieşte.

Observaţie. Pentru a adăuga un atribut nou se face clic pe punctul verde asociat atributelor (vezi figura 16). După ce a fost adăugat atributul, se face dublu clic pe noul atribut creat şi va apărea o fereastră asemănătoare celei din figura 17. Cu ajutorul ferestrei, se poate completa vizibilitatea (publică, privată, protejată), numele, tipul acestuia, valoarea iniţială şi valoarea/valorile pe care nu le poate avea atributul selectat.

Fig.17. Proprietăţile unei atribut al unei clase.

6. Se adaugă încă două clase: „Monitor” şi „Tastatură”. Clasa „Monitor” va avea două atribute publice: Rezoluţie şi Contrast, iar clasa „Tastatură”, doar un singur atribut privat: NumărTaste.

7. Se creează clasa „Calculator”, care va avea 3 atribute derivate: PlacaDeBază, Tastatură şi Monitor, precum şi două metode publice: Porneşte şi Opreşte.

8. Clasele „PlacaDeBază” şi „Tastatură” vor fi conectate de clasa „Calculator” folosind elementul Generalizare, iar pentru a conecta clasa „Monitor” de clasa „Calculator” se va folosi elementul Agregare. Se vor completa câmpurile acestui element ca în figura 18.

.

Fig. 18. Câmpurile ce descriu un element de agregare.

Completând elementul de agregare cu valorile din figura 18, se spune că un calculator poate conţine cel puţin un monitor.

9. Se salvează diagrama UML cu un nume de forma nume_student-tip_diagrama-data. La sfârşit ar trebui să apară o diagramă ca în figura 19.

Fig. 19. Diagrama rezultată după urmarea paşilor de mai sus.

10. Procedând într-un mod similar, creaţi diagramele din figurile 20 şi 21.

Fig. 20. Diagramă de tip caz de utilizare – exemplu.

Fig. 21. Diagramă de stare – exemplu.

5. Întrebări

1. Ce este o diagramă UML şi care este rolul acesteia?

2. Ce este o diagramă UML de tip clasă? Dar o diagramă UML de tip stare?

3. Care este elementul principal dintr-o diagramă de tip cazuri de utilizare?

4. Care sunt elementele principale ale diagramei de stare?

5. Ce reprezintă funcţia de agregare? Dar funcţia de generalizare?

6. Diagrama de la punctul 9 din desfăşurarea lucrării este o diagramă UML corectă? Dacă nu, ce ar trebui făcut pentru a o corecta?

7. Care sunt paşii necesari pentru ştergerea unui element din zona de lucru?

8. Creaţi o diagramă UML care să conţină cel puţin o clasă, o interfaţă şi un pachet, pe care să le definiţi corespunzător.

9. Ce elemente au fost utilizare pentru construcţia ultimei diagrame prezentate în desfăşurarea lucrării?

10. Care sunt paşii necesari pentru a salva o diagramă UML? Dar pentru salvarea unei zone de lucru?

11. Care sunt elementele de legătură pentru diagrama de tip clasă, aşa cum rezultă din rularea aplicaţiei?

12. Cum se adaugă mai multe atribute într-o clasă?

13. Cum se face legătura dintre o clasă şi o interfaţă?

14. Detaliaţi modul în care aţi creat sistemul din diagrama prezentată în figura 20.

15. Ce consideraţi că ar trebui modificat sau adăugat la prezenta aplicaţie? Propuneţi soluţii de optimizare a acesteia.