Ingineria Programarii: Diagrame UML

Capitolul 5
Diagrame UML
1. Obiective
2. Diagrame principale ale UML
3. Altova UModel
4. Aplicaii
1. Obiective
Limbajul Unificat de Modelare (engl. Unified Modeling
Language, UML) este un limbaj pentru specificarea, vizualizarea,
construirea i documentarea elementelor sistemelor software. Este un
standard de facto pentru modelarea software. Obiectivele capitolului 5 sunt
urmtoarele:
1. Prezentarea celor mai importante tipuri de diagrame UML 2.0;

2. Introducerea programului Altova UModel pentru desenarea
diagramelor UML:
a. Utilizarea diagramei de clase pentru generarea automat de
cod C#;
b. Generarea automat a diagramei de clase pe baza codului
surs C#;
c. Desenarea unor diagrame de cazuri de utilizare, clase,
activiti i secvene.
2. Diagrame principale ale UML

2.1. Diagrama cazurilor de utilizare
O diagram de nivel nalt util n multe situaii este diagrama
cazurilor de utilizare, care descrie mulimea de interaciuni dintre utilizator
i sistem. Prin construirea unei colecii de cazuri de utilizare, putem descrie
ntregul sistem ntr-o manier clar i concis. Cazurile de utilizare sunt
denumite de obicei printr-o combinaie verb-substantiv, de exemplu:
105
Florin Leon (2012). Aplicatii de ingineria programarii in C#, Tehnopress, Iasi, ISBN 978-973-702-909-6
http://florinleon.byethost24.com
Florin Leon Aplicaii de ingineria programrii n C#
Pltete factura, Creeaz cont etc. Notaia pentru un caz de utilizare este
prezentat n figura 5.1.
Figura 5.1. Caz de utilizare
Un caz de utilizare trebuie s aib un iniiator al aciunii, numit

actor. n cazul unui sistem bancar, retragerea banilor este fcut de clieni,
astfel nct clientul devine unul din actori (figura 5.2).
Figura 5.2. Caz de utilizare cu actor
Actorii nu sunt numai oameni, ci orice cauz extern care iniiaz un

caz de utilizare, de exemplu un alt sistem de calcul sau un concept mai
abstract, precum timpul, de exemplu n ultima zi a lunii se actualizeaz
statele de salarii. Pentru majoritatea sistemelor, un anumit actor poate
interaciona cu mai multe cazuri de utilizare, iar un anumit caz de utilizare
poate fi iniiat de actori diferii (figura 5.3).
Figura 5.3. Cazuri de utilizare cu actori multipli
106
Capitolul 5. Diagrame UML
2.2. Diagrama de clase

Modelarea conceptual (numit i modelarea domeniului) este
activitatea de identificare a conceptelor importante pentru sistem. n cazul
proiectrii orientate obiect, modelarea conceptual se realizeaz prin
diagrama claselor, ntruct clasele reprezint concepte. Diagrama claselor
furnizeaz structura codului care urmeaz s fie scris. Problema principal
este identificarea conceptelor. Regula de urmat aici este: dac clientul nu
nelege conceptul, probabil c nu este un concept.
O clas se reprezint printr-o csu mprit n trei (figura 5.4). n
partea de sus este notat numele clasei, n partea median sunt incluse
atributele (cmpurile) iar n partea de jos operaiile (metodele) sale.
Figura 5.4. O clas n notaia UML
n figura 5.5 sunt prezentate notaiile pentru vizibilitatea atributelor

i operaiilor (private, protejate, publice).
Figura 5.5. Vizibilitatea atributelor i operaiilor
2.2.1. Dependena
Relaia de dependen apare cnd o clas folosete pentru scurt timp

o alt clas, de exemplu trimiterea unui mesaj (apelarea din clasa A a unei
metode din clasa B) sau trimiterea ca parametru ntr-o metod a clasei A a
107
unui obiect de tip B. n C#, un exemplu este clasa Math, ale crei metode
statice sunt apelate punctual de obiectele altor clase. Se noteaz cu linie
punctat cu o sgeat (figura 5.6).
Figura 5.6. Relaia de dependen
2.2.2. Asocierea
Linia simpl n UML are rolul de asociere: o clas A are un cmp

instaniat din cealalt clas B. Numerele descriu cardinalitatea asocierii,
adic ne spun cte instane sunt permise din fiecare clas. Figura 5.7
prezint cteva cardinaliti posibile, dei din punct de vedere al notaiei nu
exist restricii asupra cardinalitilor care pot fi specificate.
Figura 5.7. Cardinaliti
O greeal pe care o putem face n faza de analiz este s trasm o

linie ntre dou clase, dar s nu notm numele asocierii. Dup ce vom trasa
toate liniile, nu vom mai ti ce nseamn fiecare.
108
n figura 5.8 este prezentat un exemplu de asociere ntre clase,

corespunztor fazei de analiz.
Figura 5.8. Asociere mai complex
Asocierile de mai sus sunt bidirecionale. ntr-o asociere

unidirecional, cele dou clase sunt nrudite, dar numai o clas tie c exist
relaia respectiv. n situaia din figura 5.9, managerul tie despre adres,
dar adresa nu tie despre manager.
Figura 5.9. Asociere unidirecional
109
2.2.3. Agregarea i compunerea
n cazul agregrii, un obiect este construit din altele. De exemplu, un

calculator este o agregare ntre procesor, plac video, plac de sunet etc.
(figura 5.10).
Figura 5.10. Relaia de agregare
Compunerea este un concept similar cu agregarea, ns mai puternic,

deoarece implic faptul c ntregul nu poate exista fr pri. n exemplul de
agregare de mai sus, dac se nltur placa de sunet, calculatorul rmne
calculator. ns o carte nu poate exista fr pagini; o carte este compus din
pagini. Notaia este asemntoare, dar rombul este plin (figura 5.11).
Figura 5.11. Relaia de compunere
2.2.4. Motenirea
De multe ori, mai multe clase au atribute i operaii comune. Acestea

pot fi introduse ntr-o singur clas i motenite n celelalte, de exemplu
clasele din figura 5.12.
Dac am mai vrea s adugm o clas Pisic, ar trebui s repetm
atributele i operaiile comune. Soluia este motenirea dintr-o clas mai
general.
110
Figura 5.12. Clase cu potenial de generalizare
Notaia UML pentru motenire (generalizare) este cea din figura 5.13.
Figura 5.13. Relaia de motenire
Trebuie s subliniem faptul c atributul vrst a fost transformat din

privat n protejat, pentru a putea fi accesat n clasele derivate.
111
2.2.5. Metode abstracte i virtuale
Clasele derivate pot redefini implementarea unor metode. n

exemplul urmtor, clasele Lup, Pete i AltAnimal sunt derivate din clasa
Animal, ns primele dou reimplementeaz metoda Mnnc n modul lor
specific. Notaia n acest caz este cea din figura 5.14.
Figura 5.14. Notaia pentru metode virtuale
Cuvintele introduse ntre << i >> se numesc stereotipuri.

De multe ori avem nevoie s lsm o metod neimplementat ntr-o
clas (metod abstract) i s o implementm pe un nivel mai de jos al
ierarhiei. Clasele i metodele abstracte se noteaz cu italice (figura 5.15).
Figura 5.15. Notaia pentru clase i metode abstracte
112
2.2.6. Interfee
S presupunem c InstrumentMuzical din exemplul precedent e

acum o interfa iar clasele Pian i Vioar trebuie s implementeze metoda
Cnt. Notaia este asemntoare celei de la motenirea de clase, dar cu linie
punctat, iar interfaa poate fi declarat explicit cu un stereotip (figura 5.16).
Figura 5.16. Notaia pentru interfee
2.2.7. Trsturi statice
n notaia UML, trsturile (atributele/cmpurile i

operaiile/metodele) statice se subliniaz, ca n figura 5.17.
Figura 5.17. Notaia pentru trsturi statice
113
2.3. Diagrame de activiti

Diagramele de activiti sunt folosite pentru modelarea proceselor
sau a algoritmilor din spatele unui anumit caz de utilizare. Notaia este
urmtoarea:
nod iniial: un cerc plin; este punctul de start al diagramei;

nod final: un cerc plin nconjurat de un alt cerc; o diagram poate
avea 0, 1 sau mai multe noduri finale;
aciuni: dreptunghiurile rotunjite reprezint paii activi executai n
cadrul procesului;
arce: sgeile diagramei;
punct final al fluxului: un cerc cu un X n interior; indic faptul c
procesul se oprete n acest punct;
ramificaie (engl. fork): o bar neagr cu un flux de intrare i mai
multe fluxuri de ieire; denot nceputul unor activiti desfurate n
paralel;
reunire (engl. join): o bar neagr cu mai multe fluxuri de intrare
i un flux de ieire; denot sfritul prelucrrilor paralele;
condiie: text asociat unui flux care definete o propoziie cu o
valoare de adevr i care trebuie s fie adevrat pentru continuarea
execuiei;
decizie: un romb cu un flux de intrare i mai multe fluxuri de ieire;
fluxurile de ieire includ condiii;
mbinare (engl. merge): un romb cu mai multe fluxuri de intrare i
un flux de ieire; toate fluxurile de intrare trebuie s ating acest
punct pentru ca procesul s continue;
partiie sau culoar (engl. partition / swimlane): o parte a diagramei
care indic cine ndeplinete aciunile;
not: un comentariu care poate aduce informaii suplimentare
privind scopul, utilizarea sau constrngerile unei entiti.
n figura 5.18 este prezentat o diagram de activiti cu decizii.

Candidatul trebuie s fie admis este o not asociat unei decizii.
114
Figura 5.18. Diagram de activiti cu decizii
n figura 5.19 este prezentat o alt diagram de activiti, cu partiii

i ramificaii.
115
Figura 5.19. Diagram de activiti cu partiii i ramificaii
116
2.4. Diagrama de secvene

Diagrama de secvene pune accentul pe aspectul temporal (ordonarea
mesajelor). Notaia grafic este un tabel care are pe axa X obiecte, iar pe axa
Y mesaje ordonate cresctor n timp. Axa Y arat pentru fiecare obiect
timpul ca o linie vertical punctat, numit linia vieii unui obiect (engl.
lifeline) i perioada n care obiectul deine controlul execuiei
(reprezentat printr-un dreptunghi) i efectueaz o aciune, direct sau prin
intermediul procedurilor subordonate.
n figura 5.20 este descris interaciunea dintre doi abonai ai unei
reele de telefonie. De remarcat c n diagrama de secvene utilizm obiecte,
nu clase. ntr-un program pot exista mai multe instane ale aceleiai clase
care au roluri diferite n sistem. Un obiect este identificat de numele su i
numele clasei pe care o instaniaz. Numele obiectului poate s lipseasc
dac nu este semnificativ pentru nelegerea comportamentului sistemului.
Liniile orizontale continue semnific mesaje iniiate de obiecte, iar liniile
orizontale punctate reprezint mesaje-rspuns.
Figura 5.20. Diagram de secvene
117
3. Altova UModel
Altova UModel este un instrument vizual pentru crearea de diagrame
UML. Poate genera cod Java, C# i Visual Basic .NET pe baza diagramelor
i poate s realizeze diagrame UML ale programelor existente. Este posibil
de asemenea ajustarea codului existent prin modificarea diagramelor
corespunztoare.
Fiecare tip de diagram are o bar de instrumente corespunztoare cu
elementele UML caracteristice, care pot fi introduse n fereastra de
desenare, conectate i modificate (figura 5.21).
Figura 5.21. Diagramele UML n Altova UModel
118
3.1. Diagrama de clase

Proprietile (cmpurile) i operaiile (metodele) unei clase pot fi
adugate mai rapid cu ajutorul tastelor F7, respectiv F8. Din bara de
instrumente sau din conectorii dreptunghiului asociat clasei se creeaz
tipurile de legturi dintre clase, de exemplu asociere, motenire etc.
Membrii unei clase pot fi redenumii direct pe diagram sau din fereastra
Model Tree.
Implicit, diagramele au vizibilitatea marcat grafic iar clasele au
prima csu colorat cu un gradient. Aspectul vizual al diagramelor poate fi
configurat folosind stilurile: View Styles. De exemplu, diagrama din
figura 5.22 sus este echivalent cu cea de jos, eliminnd gradientul i
marcnd proprietatea Show Visibility drept UML Style n loc de UModel
Style. Alte proprieti utile sunt: Show Namespace, Show Stereotypes.
Figura 5.22. Diagrame de clase cu diferite stiluri
119
3.1.1. Generarea de cod
Pentru a genera cod (C#) pe baza unei diagrame de clase, trebuie mai
nti creat un pachet care va conine clasele. n Model Tree, click dreapta pe
Root, New Element Package. Pe acest pachet trebuie aplicat profilul
limbajului dorit pentru generare: click dreapta pe pachetul creat, Code
Engineering Set as C# Namespace Root.
n pachet se introduce apoi o diagram de clase i se adaug clasele.
Tipurile proprietilor se pot completa din lista de tipuri din modelul
ales, la apsarea : dup numele proprietii (figura 5.23).
Figura 5.23. Tipurile proprietilor
Analog, pentru operaii se vor aduga parametrii i tipul de return

(figura 5.24). Numele parametrilor sunt precedate de cuvintele cheie in
(parametru normal), out (parametru out), inout (parametru ref).
Figura 5.24. Parametrii i tipul de return pentru operaii
120
Pentru o clas se pot aduga automat accesori prin click dreapta,

Create getter/setter Operations... (figura 5.25).
Figura 5.25. Adugarea de accesori
Caracteristicile specifice ale unei operaii se pot introduce din

fereastra Properties, de exemplu cu stereotipurile <<constructor>>,
<<virtual>>, <<abstract>>, <<override>> etc. (figura 5.26).
Figura 5.26. Adugarea de stereotipuri
121
Trebuie precizat faptul c aceste stereotipuri devin disponibile doar

dup crearea unui pachet setat ca C# Namespace Root, n care au fost
adugate clasele.
Vizibilitatea membrilor se poate seta de asemenea apsnd pe
imaginea din stnga numelui sau din fereastra Properties.
Se finalizeaz diagrama de clase (figura 5.27), care se poate exporta
i ca imagine din File Save Diagram As Image...
Figura 5.27. Diagram de clase cu asociere i motenire
Figura 5.28. Adugarea unui component
122
Pentru generarea efectiv a codului, mai trebuie adugat un

component n proiect, deoarece numai un astfel de element conine n
viziunea UML codul propriu-zis pentru implementare: click dreapta pe
Root, New Element Component. Dup crearea componentului, se trag
(drag and drop) clasele din diagrama de clase n component. Automat se
creeaz nite relaii de realizare (figura 5.28).
Pentru component mai trebuie specificate n fereastra Properties
limbajul de programare dorit i calea ctre directorul unde se vor genera
fiierele surs (figura 5.29).
Figura 5.29. Proprietile componentului
Apoi se face click dreapta pe numele componentului (aici

MyComponent), Code Engineering Override Program Code from
UModel Component... (figura 5.30).
Figura 5.30. Setrile pentru sincronizare
123
Scheletul de program generat pentru exemplul de mai sus este

urmtorul:
public class ClassA

{
protected int _propInt;
public virtual void OperationA1(int a, out int b, ref int c)

{
}
public int OperationA2()

{
}
}
public class ClassB : ClassA

{
private int _propertyB1;
private ClassC _propertyB2;
public bool OperationB1()

{
}
}
public class ClassC

{
private double _propertyC;
public int OperationC()

{
}
public double PropertyC

{
set { }
get { }
}
}
124
3.1.2. Crearea diagramei unui proiect existent
Importarea de cod pentru crearea diagramei de clase este destul de

simpl (figura 5.31); se alege Project Import Source Directory... pentru a
prelua fiierele surs din directorul specificat (posibil recursiv) sau Project
Import Source Project... pentru importarea unei soluii Visual Studio
(fiierul sln).
Figura 5.31. Setrile pentru generarea unei diagrame din cod
Dac se import codul generat anterior, se observ c UModel

afieaz automat relaiile de generalizare (motenire) dar nu i pe cele de
asociere (sau agregare/compunere). Acestea pot fi indicate n diagram prin
click dreapta pe un cmp i alegerea opiunii de afiare ca asociere (figura
5.32).
Relaiile de dependen nu apar automat, ns ntr-o diagram nu
trebuie s existe clase izolate. Ar nsemna c acestea nu sunt utilizate deloc
i atunci nu se justific prezena lor.
125
Figura 5.32. Afiarea unei proprieti ca asociere
S considerm urmtorul program:
namespace Dependency
{
public class A
{
public static int Add(int a, int b)
{
return a + b;
}
}
public class B
{
private int _x, _y;
private int _sum;
126
public int Sum

{
get { return _sum; }
}
public B(int x, int y)

{
_x = x; _y = y;
_sum = A.Add(_x, _y);
}
}
class Program
{
static void Main(string[] args)
{
B b = new B(1, 2);
Console.WriteLine(b.Sum);
}
}
}
La importarea sa, diagrama UModel este cea din figura 5.33.
Figura 5.33. Clasele importate

n acest caz, relaiile de dependen ntre Program i B, respectiv
ntre B i A trebuie trasate manual (figura 5.34).
Figura 5.34. Adugarea relaiilor de dependen
127
3.1.3. Aranjarea automat a elementelor din diagrame
O funcionalitate foarte util este dispunerea automat a elementelor

n fereastr (click dreapta n fereastr, Autolayout All Force Directed sau
Hierarchical).
3.2. Celelalte diagrame
Prin click dreapta pe Root, New Diagram pot fi introduse n proiect

orice diagrame UML, iar n bara de meniuri apar elementele UML specifice
tipului respectiv de diagram.
4. Aplicaii
4.1. Generai fiiere de cod C# dintr-o diagram de clase (se poate
urmri exemplul prezentat mai sus).
4.2. Realizai diagrama de clase a unui proiect C# prin importare.
4.3. Desenai diagramele din figurile: 5.3, 5.6, 5.8, 5.10, 5.11, 5.15,
5.16, 5.17, 5.18, 5.19 i 5.20.
Indicaie: Notaiile pot fi particularizate prin modificarea

proprietilor elementelor, de exemplu modificarea tipului implicit de
asociere (figura 5.35).
Figura 5.35. Modificarea tipului de asociere
128
4.4. Tem pentru acas. Desenai diagrama de activiti i diagrama

de secvene pentru un proiect C# la alegere.
Diagrama de secvene trebuie realizat manual la un nivel mai nalt,
nu diagrama realizat automat de versiunile recente ale UModel, n care
reprezentarea este la nivel de linie de cod. Diagramele astfel rezultate sunt
prea complexe pentru a fi nelese.
Diagramele trebuie exportate i n format imagine, de preferin png.
129

Ingineria Programarii: Diagrame UML

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ingineria Programarii: Diagrame UML

Uploaded by

Copyright:

Available Formats

Capitolul 5

1. Prezentarea celor mai importante tipuri de diagrame UML 2.0;

2. Diagrame principale ale UML

Figura 5.1. Caz de utilizare

Un caz de utilizare trebuie s aib un iniiator al aciunii, numit

Figura 5.2. Caz de utilizare cu actor

Actorii nu sunt numai oameni, ci orice cauz extern care iniiaz un

Figura 5.3. Cazuri de utilizare cu actori multipli

2.2. Diagrama de clase

Figura 5.4. O clas n notaia UML

n figura 5.5 sunt prezentate notaiile pentru vizibilitatea atributelor

Figura 5.5. Vizibilitatea atributelor i operaiilor

Relaia de dependen apare cnd o clas folosete pentru scurt timp

Figura 5.6. Relaia de dependen

Linia simpl n UML are rolul de asociere: o clas A are un cmp

Figura 5.7. Cardinaliti

O greeal pe care o putem face n faza de analiz este s trasm o

n figura 5.8 este prezentat un exemplu de asociere ntre clase,

Figura 5.8. Asociere mai complex

Asocierile de mai sus sunt bidirecionale. ntr-o asociere

Figura 5.9. Asociere unidirecional

2.2.3. Agregarea i compunerea

n cazul agregrii, un obiect este construit din altele. De exemplu, un

Figura 5.10. Relaia de agregare

Compunerea este un concept similar cu agregarea, ns mai puternic,

Figura 5.11. Relaia de compunere

De multe ori, mai multe clase au atribute i operaii comune. Acestea

Figura 5.12. Clase cu potenial de generalizare

Figura 5.13. Relaia de motenire

Trebuie s subliniem faptul c atributul vrst a fost transformat din

2.2.5. Metode abstracte i virtuale

Clasele derivate pot redefini implementarea unor metode. n

Figura 5.14. Notaia pentru metode virtuale

Cuvintele introduse ntre << i >> se numesc stereotipuri.

Figura 5.15. Notaia pentru clase i metode abstracte

S presupunem c InstrumentMuzical din exemplul precedent e

Figura 5.16. Notaia pentru interfee

2.2.7. Trsturi statice

n notaia UML, trsturile (atributele/cmpurile i

Figura 5.17. Notaia pentru trsturi statice

2.3. Diagrame de activiti

nod iniial: un cerc plin; este punctul de start al diagramei;

n figura 5.18 este prezentat o diagram de activiti cu decizii.

Figura 5.18. Diagram de activiti cu decizii

n figura 5.19 este prezentat o alt diagram de activiti, cu partiii

Figura 5.19. Diagram de activiti cu partiii i ramificaii

2.4. Diagrama de secvene

Figura 5.20. Diagram de secvene

Figura 5.21. Diagramele UML n Altova UModel

3.1. Diagrama de clase

Figura 5.22. Diagrame de clase cu diferite stiluri

3.1.1. Generarea de cod

Figura 5.23. Tipurile proprietilor

Analog, pentru operaii se vor aduga parametrii i tipul de return

Figura 5.24. Parametrii i tipul de return pentru operaii

Pentru o clas se pot aduga automat accesori prin click dreapta,

Figura 5.25. Adugarea de accesori

Caracteristicile specifice ale unei operaii se pot introduce din

Figura 5.26. Adugarea de stereotipuri

Trebuie precizat faptul c aceste stereotipuri devin disponibile doar

Figura 5.27. Diagram de clase cu asociere i motenire

Figura 5.28. Adugarea unui component

Pentru generarea efectiv a codului, mai trebuie adugat un