Inginerie software

Limbaje de modelare. UML

Motto
Cuvintele sunt cu adevrat mijlocul de
comunicare cel mai puin eficient.
Ele sunt cele mai expuse la interpretri
greite i cel mai adesea prost nelese.
Neale Donald Walsch
Limbaje de modelare. UML
1. UML
2. Diagrama cazurilor de utilizare
3. Modelarea conceptual. Diagrama de clase
4. Diagrame de interaciune
5. Diagrame de activiti
6. Diagrame de stri
7. Diagrama pachetelor
8. Diagrame de implementare
9. Diagrama de desfurare
Limbaje de modelare. UML
1. UML
2. Diagrama cazurilor de utilizare
3. Modelarea conceptual. Diagrama de clase
4. Diagrame de interaciune
5. Diagrame de activiti
6. Diagrame de stri
7. Diagrama pachetelor
8. Diagrame de implementare
9. Diagrama de desfurare
Probleme i soluii
n cadrul proiectelor ce presupun implicarea mai
multor participani, cu pregtiri diferite, de
formaii tehnice i culturale diferite, atingerea
unui grad nalt de acuratee i claritate este greu
de realizat. Iar costurile comunicrii eronate
cresc rapid.
O soluie la aceste probleme o constituie
utilizarea notaiilor. Notaiile permit transmiterea
n mod precis i succint a ideilor complexe.
Notaii
Pentru ca o notaie s permit comunicarea precis,
trebuie s ndeplineasc urmtoarele caracteristici:
s fie susinut de o semantic bine pus la punct,
s fie potrivit pentru a reprezenta un aspect dat al unui sistem,
s fie bine neleas de ctre participanii la proiect.
Ultima caracteristic motiveaz utilizarea standardelor i
a conveniilor: cnd o notaie este folosit de un numr
mare de participani, nu mai este loc de interpretare
greit sau ambiguitate.
UML (Unified Modeling Language), standard de notaie
n industrie, furnizeaz un spectru de notaii pentru
reprezentarea diferitelor aspecte ale unui sistem.
Modelarea
Folosirea de modele poate nlesni abordarea
problemelor complexe, facilitnd nelegerea
Divide et impera
Un model este o simplificare a unui anumit
sistem, care permite analizarea unora dintre
proprietile acestuia
Reine caracteristicile necesare
Exemple
Formalismul matematic
Reprezentrile din fizic
UML
Limbajul unificat de modelare (engl. Unified
Modeling Language)
Limbaj pentru specificarea, vizualizarea,
construirea i documentarea elementelor
sistemelor software
Poate fi folosit i pentru alte sisteme, cum ar fi
cele de modelare a afacerilor
Reprezint o colecie de practici inginereti
optime, care au fost ncununate de succes
n modelarea sistemelor mari i complexe
Scurt istoric
ntre 1989 i 1994 erau folosite mai mult de 50 de
limbaje de modelare software, fiecare cu propriile notaii
Utilizatorii doreau un limbaj standardizat, o lingua franca
a modelrii
La mijlocul anilor 90 trei metode s-au dovedit mai
eficiente:
Booch: potrivit mai ales pentru proiectare i
implementare, cu dezavantajul unor notaii complicate
OMT (Object Modeling Technique): potrivit pentru analiz
i sisteme informaionale cu multe date
OOSE (Object Oriented Software Engineering): aceast
metod a propus aa-numitele cazuri de utilizare, care
ajutau la nelegerea comportamentului ntregului sistem
Scurt istoric
1994: Jim Rumbaugh, creatorul OMT, a prsit
General Electric, alturndu-se lui Grady Booch
la Rational Corp
1995: Ivar Jacobson, creatorul OOSE, a venit la
Rational, iar ideile lui (n special conceptul de
cazuri de utilizare) au fost adugate Metodei
unificate; metoda rezultant a fost numit
Limbajul de modelare unificat UML
1996: Formarea de ctre Rational a consoriului
partenerilor UML din care fceau parte gigani
precum Hewlett-Packard, Microsoft i Oracle
UML
UML - istoric

Istoric UML
UML
Partners
Experti se
UML 1. 0
(Jan. 97)
UML 1. 1
(Sept . 97)
UML 1. 5
(March, 03)
UML 2. 0
(2004)
Other
Methods
Booch 91 OMT - 1 OOSE
Booch 93 OMT - 2
Publi c
Feedback Unif ied Method 0.8
(OOPSLA 95)
UML 0.9
(June 96)
UML 0.91
(Oct . 96)
and
Standarde
Ianuarie 1997: UML 1.0 a fost propus spre
standardizare n cadrul OMG (Object
Management Group)
Noiembrie 1997: Versiunea UML 1.1 a fost
adoptat ca standard de ctre OMG
Martie 2003: a fost publicat versiunea 1.5
Octombrie 2004: a fost introdus
versiunea 2.0
Instrumente dezvoltare UML
Visual Paradigm
IBM Rational Software Arhitect
Microsoft Visio
ArgoUML
MagicDraw UML
etc.
Limbaje de modelare. UML
1. UML
2. Diagrama cazurilor de utilizare
3. Modelarea conceptual. Diagrama de clase
4. Diagrame de interaciune
5. Diagrame de activiti
6. Diagrame de stri
7. Diagrama pachetelor
8. Diagrame de implementare
9. Diagrama de desfurare
Diagrama cazurilor de utilizare
Are rolul de a reprezenta ntr-o form grafic
funcionalitile pe care trebuie s le ndeplineasc
sistemul informatic n faza sa final.
Se utilizeaz pentru ca:
cerinele proiectului s fie definite ntr-o manier care s permit
o uoar nelegere, indiferent de nivelul de pregtire informatic
al celui care este implicat n proiect. n acest fel, modelul realizat
va putea constitui un punct de plecare n realizarea altor activiti
viitoare (alte modele, design arhitectural, implementarea propriu-
zis, testarea, verificarea i validarea sistemului).
modificrile ce apar pe parcurs n cerine s fie asimilate cu
uurin de ctre membrii echipei de dezvoltare.
delimitarea granielor sistemului s fie foarte bine realizat.
Componena diagramelor cazurilor
de utilizare
Diagramele cazurilor de utilizare sunt
formate din:
doua categorii de entiti:
actori
cazuri de utilizare
relaii ntre entiti
Cazuri de utilizare
Reprezentarea cazurilor de utilizare
semnific descrierea mulimii de
interaciuni dintre utilizator i sistem
Modeleaz un dialog ntre un actor si
sistemul informatic, realiznd o descriere a
modului n care un actor interacioneaz
cu sistemul i a modului n care sistemul
trebuie s rspund acestor interaciuni
Cazuri de utilizare
Reprezentarea grafic a cazurilor de
utilizare n UML:
Cazurile de utilizare sunt denumite, de
obicei, printr-o combinaie substantival-
verbal, de exemplu: Pltete factura,
Creeaz cont etc.
Actori
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
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 sau o anumit dat calendaristic: n ultima zi a
lunii se actualizeaz registrele de salarii
Actori
sunt roluri jucate de diverse persoane sau sisteme
informatice i care interacioneaz cu sistemul informatic
aflat n dezvoltare.
sunt entiti exterioare sistemului, putnd fi utilizatori,
echipamente hardware sau alte programe.
reprezentarea grafic a actorilor n UML este sub forma
unui omule stilizat.
fiecare actor trebuie sa aib un nume, iar numele
acestuia descrie rolul jucat de ctre actor.
Actori multipli
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
Identificarea actorilor
Identificarea actorilor se face rspunznd la
ntrebrile:
cine folosete funcionalitile principale ale
sistemului?
cine administreaz sistemul?
de cine are nevoie programul pentru a-i ndeplini
sarcinile?
cu ce echipamente sau sisteme software externe
trebuie s interacioneze sistemul?
cine dorete informaii de la sistem?
Identificarea cazurilor de utilizare
Identificarea cazurilor de utilizare se face pornind de la cerinele
utilizatorului i analiznd descrierea problemei. Se vor considera actorii deja
identificai i pentru fiecare actor se va cuta rspunsul la urmtoarele
ntrebri:
Care sunt funciile pe care actorul le ateapt de la sistem? Ce trebuie s poat
face actorul?
Are nevoie actorul s citeasc, s creeze, s modifice, s distrug sau s
pstreze anumite tipuri de informaii n sistem?
Trebuie s tie actorul de apariia unui anumit eveniment n sistem? Ce
funcionalitate reprezint aceste evenimente?
Poate actorul s-i simplifice munca de zi cu zi sau s lucreze mai eficient
folosind funcii noi ale sistemului?
Pentru identificarea cazurilor de utilizare se vor considera i alte ntrebri
care nu presupun un actor curent, cum ar fi:
Ce intrri/ieiri sunt necesare n sistem? Care sunt elementele de interaciune?
Care sunt problemele majore n implementarea curent a acestui sistem?
Relaii n diagrama cazurilor de
utilizare
Actorii pot interaciona cu sistemul astfel:
folosind sistemul, adic iniiaz execuia unor
cazuri de utilizare;
fiind folosii de ctre sistem, adic ofer
faciliti pentru realizarea unor cazuri de
utilizare.
Fiecare actor trebuie s comunice cu cel
puin un caz de utilizare
Relaii n diagrama cazurilor de
utilizare
Relaiile ce se pot stabili ntre entitile
diagramelor cazurilor de utilizare se pot
clasifica n mai multe categorii.
Astfel, o categorie consider urmtoarele
tipuri de relaii:
Relaii ntre actori i cazuri de utilizare
Relaii ntre cazuri de utilizare
Relaii ntre actori
Relaii ntre actori i cazuri de
utilizare
Relaia de asociere (comunicare)
Modeleaz o comunicare ntre elementele
pe care le conecteaz.
Se reprezint printr-o linie continu
Relaii ntre cazuri de utilizare
Relaia de utilizare (incluziune): are loc
ntre un caz de utilizare i oricare alt caz
de utilizare ce utilizeaz funcionalitatea
acestuia.
Se reprezint grafic printr-o linie
ntrerupt, avnd la captul corespunztor
cazului de utilizare folosit un triunghi i
este etichetat cu stereotipul <<Include>>.
Relaii ntre cazuri de utilizare
Relaia de extindere: reprezint o extindere a
unui caz de utilizare prin adugarea de aciuni
noi i este folosit pentru a sugera un
comportament opional, un comportament care
are loc doar n anumite condiii sau fluxuri
diferite ce pot fi selectate pe baza opiunii unui
actor (alternative).
Reprezentarea grafica este similar cu cea a
relaiei de utilizare, dar eticheta este
<<Extends>>.
Relaii ntre cazuri de utilizare
Exemplu de relaii de dependen
Relaii ntre cazuri de utilizare
Relaia de generalizare: abstractizarea unei
relaii dintre dou cazuri de utilizare a crei
semantic este exprimat astfel: un caz de
utilizare este printe, cellalt este fiu (copil).
Orice element din categoria conceptual printe
poate fi substituit de un element din categoria
conceptual fiu.
Notaia UML este
Relaii ntre actori
Relaia de generalizare: semnific faptul
c un actor poate interaciona cu sistemul
n toate modalitile prin care
interacioneaz un altul.
Practic, un actor motenete structura i
comportamentul unui actor sau mai multor
actori.
Reprezentarea UML:
Relaii ntre actori
Relaia de dependen: semnifica faptul
ca, pentru a interaciona cu sistemul
informatic prin intermediul unui caz de
utilizare, un actor depinde de alt actor.
n UML se reprezint printr-o linie
ntrerupt avnd la un capt o sgeat:
Specificarea relaiilor n diagrama
cazurilor de utilizare
Pentru specificarea relaiilor din cadrul unei diagrame a cazurilor de
utilizare se vor considera urmtoarele ntrebri:
Toi actorii implicai comunic cu cazuri de utilizare?
Sunt asemnri ntre actori, astfel nct s se considere un actor de
baz?
Sunt asemnri ntre cazurile de utilizare existente? Exist un flux
comun de activiti care s poat fi descris ca o relaie de utilizare a
unui caz de utilizare?
Exist cazuri de utilizare care s poat fi descrise ca extend-uri?
Sunt actori sau cazuri de utilizare fr asocieri de comunicare? Dac
da, se va reanaliza diagrama pentru eliminarea unor astfel de situaii!
Sunt cerine funcionale nc necuprinse n cazuri de utilizare? Dac da,
vor trebui rezolvate.
Precizare
Cazurile de utilizare sunt orientate pe
scop: reprezint ceea ce trebuie s fac
sistemul i nu cum este implementata o
anumita funcionalitate.
Importana cazurilor de utilizare
Definesc domeniul sistemului, permind vizualizarea dimensiunii i
sferei de aciune a ntregului proces de dezvoltare
Sunt similare cerinelor, dar cazurile de utilizare sunt mai clare i
mai precise datorit structurii riguroase de notaie
Mulimea de cazuri de utilizare a unui sistem reprezint toate
modalitile n care poate fi folosit sistemul
Suma cazurilor de utilizare este sistemul ca ntreg; ceea ce nu este
acoperit de un caz de utilizare se situeaz n afara sistemului de
construit
Permit comunicarea dintre client i dezvoltatori, de vreme ce
diagrama este foarte simpl i poate fi neleas de oricine.
Ghideaz echipele de dezvoltare n procesul de dezvoltare a
sistemului
Ajut echipele de testare i autorii manualelor de utilizare
Granularitate
ntr-un anumit scenariu, fiecare
interaciune utilizator-sistem trebuie s fie
un caz de utilizare
sau
Un singur caz de utilizare poate ncapsula
toate interaciunile
Aa nu
Regul euristic
Un caz de utilizare trebuie s satisfac un
scop pentru actor
n exemplul anterior, scopul clientului este
de fapt retragerea unei sume de bani
Reprezentare corect:
Exemple de creare diagrame cazuri
de utilizare
Exemplu Rational
Exemplu Visual-Paradigm
Exemplu Altova
Exemplu Visio
Exemplu Rational
Exemplu Visual-Paradigm
Exemplu Altova
Exemplu Visio
Exemplu
Se consider o aplicaie pentru gestionarea proiectelor studenilor.
Utilizatorii aplicaiei trebuie s se autentifice pentru a utiliza
aplicaia. Toi utilizatorii trebuie sa aib posibilitatea modificrii
parolei proprii. Exist dou tipuri de utilizatori: studeni i profesori.
Aplicaia pune la dispoziia studenilor o modalitate de a vedea lista
proiectelor disponibile i o modalitate de a selecta un proiect din
aceasta lista. De asemenea, un student are posibilitatea s renune
la un proiect selectat. Trebuie specificat faptul c exista o lista de
categorii i fiecare proiect se ncadreaz ntr-o singur categorie
dintre cele existente. Aplicaia ofer profesorilor o modalitate de a
vedea ce proiecte si-au ales studenii i ce proiecte nu au fost alese.
Diagrama cazurilor de utilizare -
exemplu
Limbaje de modelare. UML
1. UML
2. Diagrama cazurilor de utilizare
3. Modelarea conceptual. Diagrama de clase
4. Diagrame de interaciune
5. Diagrame de activiti
6. Diagrame de stri
7. Diagrama pachetelor
8. Diagrame de implementare
9. Diagrama de desfurare
Modelarea conceptual
Modelarea conceptual (numit i modelarea
domeniului) este activitatea de identificare a
conceptelor importante pentru sistem
n abordarea orientat obiect, modelarea
conceptual se realizeaz prin diagrama
claselor, ntruct clasele reprezint concepte
Diagrama claselor furnizeaz structura codului
care va fi scris
Problema principal este identificarea
conceptelor; regula de urmat aici este: dac
clientul nu nelege conceptul, probabil c nu
este un concept
Clasa
O clas se reprezint printr-o csu mprit n
trei
n partea de sus este notat numele clasei, n
partea median atributele iar n partea de jos
operaiile sale
Vizibilitatea
atributelor i operaiilor
Asocierea. Cardinalitatea
Exemplu
Agregarea
Un obiect poate fi construit din altele
Compunerea
Compunerea este un concept similar cu
agregarea, ns mai puternic deoarece
implic faptul c un ntregul nu poate
exista fr pri
Motenirea
Observaii
Atributele protejate sunt motenite n clasele
derivate dar sunt inaccesibile din exterior
Utilizarea abuziv a motenirii conduce la
dificulti n ntreinerea programului i la
urmrirea funcionalitilor (proliferarea claselor)
Motenirea nu trebuie folosit dect ca mecanism
de generalizare, adic se folosete numai dac
clasele derivate sunt specializri ale clasei de
baz
Toate definiiile clasei de baz trebuie s se aplice
tuturor claselor derivate. Aceasta este regula
100%. Dac nu se aplic aceast regul, clasele
derivate nu sunt specializri ale clasei de baz
Aa nu
Polimorfismul
Metode abstracte (virtuale)
Interfee
Metode statice
Exemple de creare diagrame clase
Exemplu IBM Rational Software Arhitect
Diagrama de obiecte
Este denumit i diagrama de instante.
Prezinta obiectele si legaturile ntre ele.
Notatia utilizata pentru diagramele de
obiecte este derivata din cea a
diagramelor de clase, elementele care
sunt instante fiind figurate subliniat
Reprezentarea grafic a obiectelor
Limbaje de modelare. UML
1. UML
2. Diagrama cazurilor de utilizare
3. Modelarea conceptual. Diagrama de clase
4. Diagrame de interaciune
5. Diagrame de activiti
6. Diagrame de stri
7. Diagrama pachetelor
8. Diagrame de implementare
9. Diagrama de desfurare
Diagrame de interaciune
Descrierea comportamentului implic dou
aspecte:
descrierea structural a participanilor
descrierea modelelor de comunicaie
Modelul de comunicaie al instanelor care joac
un rol pentru ndeplinirea unui anumit scop se
numete interaciune
Diagramele de interaciune au dou forme,
bazate pe aceleai informaii de baz, dar care
se concentreaz fiecare pe un alt aspect al
interaciunii:
diagramele de secven
diagramele de colaborare
Diagrama de secvene
Diagrama de secvene pune accentul pe aspectul
temporal (ordonarea n timp a 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 (linia vieii unui obiect, engl.
lifeline) i perioada n care obiectul preia controlul
execuiei (reprezentat printr-un dreptunghi) i
efectueaz o aciune, direct sau prin intermediul
procedurilor subordonate
Diagrama de secvene
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
Exemplu
Diagrama de colaborare
Diagrama de
colaborare se
concentreaz pe
rolurile instanelor i
relaiile dintre ele
Ea nu conine timpul
ca o dimensiune
separat, de aceea
secvena de
comunicaii i firele de
execuie concurente
trebuie numerotate
Limbaje de modelare. UML
1. UML
2. Diagrama cazurilor de utilizare
3. Modelarea conceptual. Diagrama de clase
4. Diagrame de interaciune
5. Diagrame de activiti
6. Diagrame de stri
7. Diagrama pachetelor
8. Diagrame de implementare
9. Diagrama de desfurare
Diagramele de activiti
Sunt folosite pentru modelarea proceselor sau a
algoritmilor corespunztori unui anumit caz de
utilizare
Notaia este urmtoarea:
Nod iniial: un cerc plin este punctul de start al
diagramei; dei nu este obligatoriu, prezena sa face
diagrama mai lizibil
Nod final: un cerc plin nconjurat de un alt cerc; o
diagram poate avea 0, 1 sau mai multe noduri finale
Activitate: dreptunghiurile rotunjite reprezint
activitile care au loc
Fluxuri: sgeile diagramei
Punct final al fluxului: un cerc cu un X n interior;
indic faptul c procesul se oprete n acest punct
Diagramele de activiti
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 condiie
care trebuie s fie adevrat pentru traversarea nodului
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 (engl. swimlanes): o parte a diagramei care
indic cine/ce ndeplinete activitile
Not: o specificaie suplimentar sub form de text
Exemple
Limbaje de modelare. UML
1. UML
2. Diagrama cazurilor de utilizare
3. Modelarea conceptual. Diagrama de clase
4. Diagrame de interaciune
5. Diagrame de activiti
6. Diagrame de stri
7. Diagrama pachetelor
8. Diagrame de implementare
9. Diagrama de desfurare
Diagramele de stri
Pentru a nelege comportamentele complexe ale
obiectelor se utilizeaz diagramele de stri, care descriu
modul de funcionare a instanelor
Diagramele de stri UML descriu diferitele stri n care
se poate gsi un obiect i tranziiile dintre aceste stri
O stare reprezint o etap n modelul comportamental al
unui obiect
O stare iniial este cea n care se gsete obiectul cnd
este creat
O stare final este o stare din care nu mai exist tranziii
Tranziia reprezint schimbarea strii, trecerea dintr-o
stare n alta, i poate fi determinat de un eveniment
extern sau intern
Exemplu
Exemplu
Limbaje de modelare. UML
1. UML
2. Diagrama cazurilor de utilizare
3. Modelarea conceptual. Diagrama de clase
4. Diagrame de interaciune
5. Diagrame de activiti
6. Diagrame de stri
7. Diagrama pachetelor
8. Diagrame de implementare
9. Diagrama de desfurare
Diagrama pachetelor
Entitile UML pot fi grupate n pachete
Pachetele sunt containere logice n care pot fi
plasate elemente nrudite, ca i directoarele
din sistemele de operare
Dei orice entitate UML poate fi introdus
ntr-un pachet, de obicei rolul pachetelor
este de a grupa clase i uneori cazuri de
utilizare nrudite.
Diagrama pachetelor
ntr-un pachet UML numele elementelor trebuie s
fie unice
Un avantaj important al pachetelor este c mai
multe clase pot avea acelai nume dac aparin
unor pachete diferite
Dac dou echipe A i B lucreaz n paralel, echipa A
nu va trebui s se preocupe de coninutul pachetului
echipei B, cel puin din punctul de vedere al
denumirilor
Utilitatea pachetelor:
elementele sistemelor mari pot fi grupate n
subsisteme mai mici
este permis dezvoltarea iterativ n paralel
Formarea pachetelor
Un pachet trebuie s aib o funcionalitate
bine precizat, el nu trebuie s
ndeplineasc funcii multiple, deoarece
devine greu de neles
Dependenele dintre pachete trebuie s fie
minime
Exemplu
Limbaje de modelare. UML
1. UML
2. Diagrama cazurilor de utilizare
3. Modelarea conceptual. Diagrama de clase
4. Diagrame de interaciune
5. Diagrame de activiti
6. Diagrame de stri
7. Diagrama pachetelor
8. Diagrame de implementare
9. Diagrama de desfurare
Diagrame de implementare sau
Diagrama componentelor
Diagrama componentelor este
asemntoare cu diagrama pachetelor,
permind vizualizarea modului n care
sistemul este divizat i a dependenelor
dintre module
Diagrama componentelor pune ns
accentul pe elementele software fizice
(fiiere, biblioteci, executabile) i nu pe
elementele logice, ca n cazul pachetelor
Diagrame de implementare (II)
O component poate s conin cod surs
sau s fie n form binar sau executabil.
O component se mapeaz, de obicei, pe
una sau mai multe clase, interfee sau
colaborri => diagrama de implementare
are legtur cu diagrama de clase.
Diagrama de componente reflect vederea
static de implementare asupra sistemului.
Exemplu
Limbaje de modelare. UML
1. UML
2. Diagrama cazurilor de utilizare
3. Modelarea conceptual. Diagrama de clase
4. Diagrame de interaciune
5. Diagrame de activiti
6. Diagrame de stri
7. Diagrama pachetelor
8. Diagrame de implementare
9. Diagrama de desfurare
Diagrama de desfurare (lansare)
Diagramele de lansare (engl. deployment
diagrams) descriu configuraia elementelor de
prelucrare la run-time i componentele software,
procesele i obiectele care se execut pe ele
Aceste diagrame sunt grafuri de noduri
conectate de asociaii de comunicare
Nodurile pot conine instane ale componentelor,
indicnd faptul c acea component ruleaz sau
se execut n nodul respectiv
Nodurile sunt reprezentate prin paralelipipede
Cercurile reprezint interfee
Diagrama de desfurare (II)
Indic arhitectura fizic pe care este
implementat sistemul, calculatoarele,
dispozitivele (noduri ale sistemului) i
conexiunile dintre ele.
Exemplu
Concluzii
UML este un limbaj pentru specificarea,
vizualizarea, construirea i documentarea
elementelor sistemelor software
Este un standard de facto pentru
modelarea software
UML permite modelarea cazurilor de
utilizare i reprezentarea diagramelor de
clase, de interaciune, de activiti, de
stri, de pachete i de implementare