Documente Academic
Documente Profesional
Documente Cultură
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.
Ø 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.
Ø reacţiile primite din partea utilizatorilor care au sugerat că este mult mai
important să se acorde o atenţie sporită conceptelor utilizate în dezvoltarea
aplicaţiilor. Recomandările referitoare la desfăşurarea etapelor de realizare şi
înlăntuirea lor au fost lăsate în planul secund,
Ø 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.
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 luând în
considerare diferite aspecte:
Aşadar pentru descrierea unui sistem sunt necesare un număr de view-uri, fiecare
reprezentâ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 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 View-ul
Componentelor Logic
nt View-ul
Cazurilor
de Utilizare
View-ul View-ul
de de concurenţă
desfaşurare
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.
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ă diagrame ale
componentelor.
Sistemul poate fi construit astfel încât 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).
2.2 Diagrame
Diagramele sunt grafuri care prezintă simboluri ale elementelor de modelare (model
element) 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ă.
Semnarea unei
poliţe de asigurare
Client
Situaţia Societate
vânzărilor de asigurări
Situaţia
clienţilor
(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
1
1 are 0..* Contract de
Companie
asigurare
de asigurări apartine
0..*
refera are
1..*
Persoana
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.
Calculator
Angajat
foloseste
nume:String Diagrama claselor
nume:String 0..1 1..* memorie:Integer
virsta:Integer
PC Servici:Calculator
nume=”Dell 466”
Popescu:Angajat
memorie=64
Diagrama obiectelor
nume=”Popescu Ion”
virsta=30
PC Acasa:Calculator
nume=”Compaq
Pentium MMX”
soseste la parter
urcă (etaj)
M soseste
ută la
Staţionează
Mută jos timp=0
soseste
do/creşte timp
do/ schimba nivelul
Time-out
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.
[imprimanta ocupată]
Stochează (fişier)
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 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).
1: Print (fisier)
[imprimanta liberă]
1.1: Print(fişier)
:ServerImprimantă :Imprimanta
Afişează mesajul
[disc full] “Disc Full”
FereastraClient.AfiseazaTotiClientii() Afişează pe ecran pe ecran
fereastra de mesaj
“Printing”
Afişeaza mesajul
[spaţiu liber pe disc] “Printing”
pe ecran
Command
Hander
(comhnd.cpp)
Program
Command
Client
Hander (client.exe)
(comhnd.obj)
Main
Class
(main.cpp)
Main
Class
(main.obj)
Client A: <<TCP/IP>>
Compaq
Pro PC
<<Net 8>>
Application Database
Server: Server:
<<TCP/IP>>
Silicon Oracle
Graphics O2
Client B:
Compaq
Pro PC