Introducere in UML

Introducere in UML
Introducere n UML
1. 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 de programare. Limbajul este destinat vizualiz rii, specific rii, construirii #i document rii sistemelor de aplica&ii, dar are limit ri n ceea ce prive#te generarea codului. UML reune#te cele mai bune tehnici #i practici din domeniul ingineriei program rii, care #i-au dovedit eficien&a n construirea sistemelor complexe. Cteva date semnificative referitoare la apari&ie #i evolu&ie: n octombrie 1994, Grady Booch lider stiin&ific la Rational Corporation, autor al metodei ce-i poart numele #i a unor c r&i de referint n domeniu face echip cu James Rumbaugh, autorul principal al metodei OMT, pe care-l determin s -si p r seasc (cel pu&in temporar) vechiul loc de munc (General Electric) #i s treac la firma Rational. Dup un an de activitate Booch #i Rumbaugh, prezint n octombrie 1995 cu ocazia conferin&ei OOPSLA, caracteristicile de baz ale unei noi metode de analiz #i proiectare, rezultat prin unificarea Metodei lui Booch (OOD) cu OMT, metod denumit Metoda unificat (Unified Method). Prima documenta&ie a metodei men&ionat anterior a fost f cut public n decembrie 1995, avnd num rul de versiune 0.8. La sfrsitul aceluia#i an celor doi li se alatur #i Ivar Jacobson. In iunie 1996 apare versiunea 0.9, urmat la scurt timp, octombrie 1996, de apari&ia versiunii 0.91. Versiunea 0.9 aduce #i schimbarea denumirii din Metoda unificat (Unified Method) n Limbajul unificat de modelare (Unified Modeling Language). Cooptarea lui Jacobson n echip se concretizeaz printre altele n detalierea conceptului de cazuri de utilizare (use case) #i prezentarea unei descrieri mai am nun&ite pentru diagramele cazurilor de utilizare. Conceptul de stereotip este mai bine explicitat, se modific denumirile unor diagrame.
PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com
Introducere in UML La 11 ianuarie 1997 este prezentat versiunea 1.0 care, nso&it
2 de o
documenta&ie mult mai detaliat dect versiunile precedente, este trimis c tre OMG pentru standardizare. 1 septembrie 1997, a reprezentat un alt moment deosebit de important. Rational #i alte firme care spijina UML, printre care #i doi fosti competitori, IBM/ObjectTime #i Taskon/Reich, a propus OMG o nou versiune 1.1. Noutatea semnificativ pentru aceast versiune o reprezint introducerea limbajului OCL, un limbaj folosit pentru descrierea regulilor de corectitudine ale metamodelului UML. La 17 noiembrie 1997, OMG a anuntat adoptarea specifica&iei UML ca limbaj standard de modelare
Schimbarea denumirii din Metoda Unificat n Limbaj de Modelare Unificat a fost justificat prin: reac&iile primite din partea utilizatorilor care au sugerat c este mult mai se acorde o aten&ie sporit conceptelor utilizate n dezvoltarea
important s
aplica&iilor. Recomand rile referitoare la desf #urarea etapelor de realizare #i nl ntuirea lor au fost l sate n planul secund,
faptul c eforturile de unificare au fost concentrate asupra limbajului grafic de
modelare, asupra semanticii lui #i abia dup aceea asupra modului de utilizare a conceptelor,
UML a fost conceput ca un limbaj universal care s fie utilizat la modelarea
sistemelor (indiferent de tipul #i scopul pentru care au fost construite), la fel cum limbajele de programare sunt folosite n diverse domenii.
Sublinierea aspectelor de limbaj nu semnific nicidecum ignorarea modului de folosire a lor. UML presupune c metodologia este ghidat de cazurile de utilizare, c ea se bazeaz pe arhitectura sistemului, iar procesul de aplicare a metodologiei este iterativ #i incremental. Detaliile acestui proces trebuie adaptate la domeniul aplica&iei, la modul de organizare al
Introducere in UML echipei de realizatori, la experien&a echipei. UML nu trateaz
3 aspecte de metodologie,
permitnd astfel separarea limbajului de modelare de procesul aplic rii metodologiei.
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 descrierea sistemului 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 lund n considerare diferite aspecte: cod; Func#ional: este descris #i comportamentul dinamic al
structura static
sistemului; Non-func#ional: necesarul de timp pentru dezvoltarea sistemului Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de
Introducere in UML
A#adar pentru descrierea unui sistem sunt necesare un num r de view-uri, fiecare reprezentnd 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 relative la un anumit aspect particular al sistemului. Aceste view-uri se acoper unele pe altele, deci este posibil ca o anumit diagram s fac parte din mai multe view-uri.
View-ul Componentelor nt
View-ul
Logic
View-ul Cazurilor de Utilizare View-ul de concuren&
View-ul de desfa#urare
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 actorii externi care interac&ioneaz cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme. n componen&a lui intr diagrame ale cazurilor de utilizare #i ocazional, diagrame de activitate. Cei interesa&i de acest view sunt deopotriv clien&ii, designerii, dezvoltatorii dar #i cei care 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 untrul sistemului #i descrie att structura intern a acestuia (clase, obiecte #i rela&ii) ct #i colabor rile care apar cnd obiectele trimit unul altuia mesaje pentru a realiza func&ionalitatea dorit . Structura static este descris n diagrame de clas , n timp ce pentru modelarea dinamicii sistemului se vor folosi diagramele de stare, de secvent , de colaborare sau de activitate. Prin urmare, cei care sunt interesa&i de acest tip de vizualizare a sistemului sunt designerii #i dezvoltatorii.
Introducere in UML
View-ul componentelor (Component View)
Componentele sunt module de cod de diferite tipuri. n func&ie de con&inutul lor acestea pot fi: componente care con&in cod surs , componente binare sau excutabile. View-ul componentelor are rolul de a descrie componentele implementate de sistem #i dependen&ele ce exist ntre ele, precum #i resursele alocate acestora #i eventual alte informa&ii administrative, cum ar fi de exemplu un desfa#ur tor al muncii de dezvoltare. Este folosit n special de dezvoltatorii sistemului, iar n componen&a sa intr componentelor. View-ul de concuren& (Concurent View) diagrame ale
Sistemul poate fi construit astfel nct s ruleze pe mai multe procesoare. Acest aspect, care este unul nonfunc&ional, este util pentru o gestionare eficient a resurselor, execu&ii paralele #i trat ri asincrone ale unor evenimente din sistem, precum #i pentru rezolvarea unor probleme legate de comunicarea #i sincronizarea theadu-urilor. Cei care sunt interesa&i de o astfel de vizualizare a sistemului sunt dezvoltatorii #i integratorii de sistem, iar pentru construirea lui se folosesc diagrame dinamice (stare, secvent , colaborare #i activitate) #i diagrame de implementare (ale componentelor sau de desf #urare). View-ul de desf surare (Deployment View)
Desf #urarea fizic a sistemului, ce calculatoare #i ce device-uri (numite #i noduri) vor fi folosite pentru realizarea efectiv a implement rii, cum sunt acestea conectate, precum #i ce componente se vor executa pe fiecare nod (de exemplu ce program sau obiect este executat pe fiecare calculator), toate sunt surprinse n view-ul de desf #urare. Aceast tip de vizualizare a sistemului prezint interes sunt dezvoltatori, integratorii de sistem #i cei care realizeaz testarea sistemului, iar pentru construirea view-ului este folosit diagrama de desf #urare.
Introducere in UML 2.2 Diagrame
Diagramele sunt grafuri care prezint simboluri ale elementelor de modelare (model element) aranjate astfel nct 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)
Un caz de utilizare este o descriere a unei func&ionalit &i (o utilizare specific a sistemului) pe care o ofer sistemul. Diagrama prezint actorii externi #i cazurile de utilizare identificate, numai din punctul de vedere al actorilor (care este comportamentul sistemului, a#a cum este el perceput de utilizatorii lui?) nu #i din interior, precum #i conexiunile identificate ntre actori #i cazurile de utilizare. Un exemplu de diagram a cazurilor de utilizare este prezentat n figura 2.
Semnarea unei poli&e de asigurare Client Situa&ia vnz rilor
Societate de asigur ri
Situa&ia clien&ilor
Figura 2: O diagram a cazurilor de utilizare dintr-un sistem de asigur ri.
Diagrama claselor (Class Diagram) O diagram a claselor prezint structura fizic a claselor identificate n sistem. Clasele reprezint lucruri gestionate de sistem; clasele pot fi legate n mai multe moduri: asociate
Introducere in UML
(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). Toate aceste 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 de via& al sistemului. Un exemplu de diagram a claselor este prezentat n figura 3.
Poli&a de asigurare 0..1

expim este expimat prin
1
Companie de asigur ri
are apartine
0..*
Contract de asigurare 0..*

refera are
1..* Persoana
Figura 3: O diagram a claselor pentru un sistem de asigur ri.
Diagrama obiectelor (Object Diagram)
Acest tip de diagram este un variant al diagramei claselor care n locul unei clase prezint mai multe instan&e ale ei. Diagrama obiectelor folose#te aproape acelea#i nota&ii ca #i diagrama claselor cu dou mici diferen&e: obiectele sunt scrise subliniat #i sunt vizualizate toate 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 vizualizari ale instan&elor actuale #i a rela&iilor exact a#a cum sunt ele realizate. Mai poate fi folosit ca o parte a diagramelor de colaborare, n care sunt vizualizate colabor rile dinamice existente n cadrul unui set de obiecte.
Introducere in UML
Angajat nume:String virsta:Integer

0..1
Calculator
foloseste 1..*
nume:String
Diagrama claselor
memorie:Integer
PC Servici:Calculator Popescu:Angajat
nume=Popescu Ion virsta=30 nume=Dell 466
memorie=64
Diagrama obiectelor
PC Acasa:Calculator
nume=Compaq Pentium MMX Figura 4: O diagram a claselor $i o diagram a obiectelor (instan#ele claselor). Diagrama de stare (State Diagram) O stare este de obicei un complement al descrierii unei clase. O diagram de stare prezint 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 de stare este prezentat n figura 5.
La parter
urca (etaj)
Mut sus do/ schimb nivelul
soseste la parter
M ut la
Mut jos do/ schimba nivelul
soseste
urc (etaj) soseste
Sta&ioneaz timp=0 do/cre#te timp
Time-out
Figura 5: O diagram de stare pentru un ascensor
Introducere in UML
Nu vom construi diagrame de stare pentru toate clasele din sistem ci numai pentru acelea care au un num r de st ri bine definit iar comportamentul clasei este afectat #i modificat de acestea.
Diagrama de secven& (Sequence Diagram)
O diagram de secven# prezint colaborarea dinamic ntre un num r de obiecte (vezi figura 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 este reprezentat pe axa vertical de sus n jos. Mesajele sunt reprezentate prin s ge&i ntre linile verticale ce corespund obiectelor implicate n mesaj.
:Calculator :Server de imprimanta :Imprimanta :Coada
Print (fisier)
[imprimanta liber ] Print (fi#ier) [imprimanta ocupat ] Stocheaz (fi#ier)
Figura 6: Diagrama de secven# pentru un server de imprimant
Diagrama de colaborare (Collaboration Diagram)
Aceast diagram surprinde colaborarea dinamic ntre obiecte, ntr-o manier similar cu a diagramei de secven& , dar pe lng schimbul de mesaje (numit #i interac#iune) prezint obiectele #i rela&iile dintre ele (cteodat referite ca #i context).
Introducere in UML
10
Cum decidem ce tip de diagram s folosim? Dac cel mai important aspect este timpul sau 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 de etichete care specific ordinea n care acestea vor fi transmise. De asemenea se pot vizualiza condi&ii, itera&ii, valori returnate, precum #i obiectele active care se execut concurent cu alte obiecte active (vezi figura 7).
:Calculator
[imprimanta ocupat ] 1.2: Stocheaz (fi#ier)
:Coada de a#teptare
1: Print (fisier)
[imprimanta liber ] 1.1: Print(fi#ier)
:ServerImprimant
:Imprimanta
Figura 7: O diagram de colaborare pentru un server de imprimant . Diagrama de activitate (Activity Diagram)
O diagram de activitate prezint fluxul secven&elor de activita&i, ca n figura 8, #i este de 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 sau recep&ionate ca parte a ac&iunii realizate.
Introducere in UML
11
[disc full] FereastraClient.AfiseazaTotiClientii() Afi#eaz pe ecran fereastra de mesaj Printing
Afi#eaz mesajul Disc Full pe ecran
[spa&iu liber pe disc]
Afi#eaza mesajul Printing pe ecran
'terge fereastra de mesaj
^Printer.Print(fisier)
Creaza fi#ierul postscript
Figura 8: O diagram de activitate pentru un server de imprimant . Diagrama componentelor (Component Diagram)
O diagram
a componentelor prezint
structura fizic
a codului n termenii
componentelor de cod, realiznd o mapare de la view-ul logic la view-ul componentelor. O component 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 o vizualizare simpl a componentelor care vor fi afectate de modificarea uneia dintre ele.
Window Hander
(whnd.cpp)
Window Hander
(whnd.obj)
Graphic Lib
(graphic.dll)
Command Hander
(comhnd.cpp)
Command Hander
(comhnd.obj)
Program Client
(client.exe)
Main Class
(main.cpp)
Main Class
(main.obj)
Figura 8: O diagram a componentelor
Introducere in UML Diagrama de desf #urare (Deployment View)
12
Arhitectura fizic
pe care va fi implementat sistemul, calculatoarele, device-urile
(referite ca nodurile sistemului), mpreun cu conexiunile dintre ele, vor putea fi prezentate n cadrul unei diagrame de desfa$urare. Componentele #i obiectele executabile sunt alocate n interiorul nodurilor, ceea ce ne va permite o vizualizare a unita&ilor care se vor executa pe fiecare nod.
Client A: Compaq Pro PC
<<TCP/IP>>
<<TCP/IP>>
Application Server: Silicon Graphics O2
<<Net 8>>
Database Server: Oracle
Client B: Compaq Pro PC
Figura 9: O diagram de desfa$urare care prezint structura fizic
a sistemului.

Introducere in UML

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Introducere in UML

Încărcat de

Drepturi de autor:

Formate disponibile

Introducere in UML

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

faptul c eforturile de unificare au fost concentrate asupra limbajului grafic de

UML a fost conceput ca un limbaj universal care s fie utilizat la modelarea

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com