Inginerie Software

Elemente de Inginerie Software

Ingineria software reprezintă abordarea sistematică a dezvoltării,

funcţionării, întreţinerii şi retragerii din funcţiune a programelor.

Ingineria programării este stabilirea şi utilizarea de principii

inginereşti solide pentru a obţine în mod economic programe sigure şi care
funcţionează eficient pe maşini de calcul reale.
 Ingineria software
Acest domeniu:
▪are ca scop dezvoltarea metodelor, instrumentelor şi tehnicilor ce pot asigura un proces
de producere software controlat, rezultatul fiind sisteme software performante şi fiabile.
▪este legat de tehnologii şi practici aparţinând ştiinţei calculatoarelor, managementului
proiectelor, ingineriei, proiectării interfeţelor şi altor domenii.
▪este în relaţie cu alte discipline de inginerie: inginerie de sistem şi gestiune de
proiecte, siguranţa şi fiabilitatea sistemelor.
▪se preocupă de procedeele de construire software, astfel încât să fie îndeplinite
următoarele criterii:
- sistemul creat răspunde nevoilor utilizatorilor;
- calitatea corespunde contractului de service iniţial;
- costurile rămân în limitele prevăzute iniţial;
- întârzierile rămân în limitele prevăzute iniţial.
 Ingineria software
Principalele ramuri ale ingineriei software acoperă:

▪tehnicile de specificare;
▪tehnicile de concepţie;
▪tehnicile de validare/verificare;
▪gestiunea proiectelor;
▪aspectele socio-economice ale proiectelor de dezvoltare a produselor
software.
 Tehnici de specificare
Prin specificare înţelegem o descriere a unor caracteristici ale produsului final, (un
program sau o aplicaţie formată dintr-un sistem de programe) care trebuie să fie
realizat în mod obligatoriu de către proiectant (programator) pentru ca produsul să
poată fi acceptat şi utilizat de beneficiarul său.
Corespunzător, există diferite tehnici de specificare, caracteristice fiecărei
faze de dezvoltare:
▪tehnici de specificare a cerinţelor sau a exigenţelor funcţionale şi nefuncţionale
(eficacitate, dimensiuni, siguranţă în funcţionare etc.); se aplică în faza de analiză a
cerinţelor şi se exprimă, în general, în limbaj natural;
▪ tehnici de specificare a sistemului; se aplică în faza de analiză de sistem şi se referă la
natura funcţiilor oferite, la comportamentul dorit şi la datele necesare pentru realizarea
funcţiilor;
▪tehnici de specificare a arhitecturii sistemului; se aplică în faza de concepţie generală
şi definesc modulele de arhitectură ce urmează să fie realizate;
▪tehnici de specificare tehnică (sau de detaliu); se aplică în faza de proiectare detaliată a
modulelor, programelor şi structurilor de date.
Tehnici de concepţie

Faza de concepţie constă în construirea unei prime forme a sistemului, pe

baza specificaţiilor rezultate din faza de analiză. Prin rafinarea acestei
prime forme, în etape succesive (iterativ), se obţine o imagine finală a
sitemului, imagine ce permite trecerea la etapa de realizare a programelor
(implementare).
Tehnicile de concepţie permit definirea arhitecturii logice a sistemului
proiectat într-o formă care corespunde cerinţelor funcţionale exprimate în
faza de analiză. Prin urmare, tehnicile de concepţie fac legătura între
cerinţele utilizatorului şi soluţia de programare găsită pentru
implementarea aplicaţiei.
Tehnici de validare/verificare

Verificarea sistemelor software nu se referă numai la cod

(program), acoperind toate produsele specifice fazelor ciclului de
viaţă al unui proiect informatic. Rezultatul verificării nu constă,
în mod necesar, în acceptarea sau respingerea produsului. De cele
mai multe ori, se caută anomaliile posibile în funcţionarea
produsului.
Verificarea sistemelor software este necesară, în primul
rând, pentru descoperirea erorilor de concepţie care pot influenţa
funcţionalitatea produsului (caz în care verificarea constă în
testarea comportamentului produsului în diverse contexte de
funcţionare), sau pentru identificarea cauzelor unor defecţiuni
care apar în funcţionarea curentă a produsului.
Există două moduri de abordare a procesului de verificare, care
trebuie să fie considerate complementare:
 verificare dinamică (numită şi verificare experimentală sau
testarea produsului) a comportamentului produsului folosind
seturi de date care simulează condiţiile reale de exploatare;
 verificare statică şi analiza proprietăţilor produsului, fără
simularea execuţiei programelor componente.
Verificare dinamică

Se efectuează jocuri de test (de încercare) care nu pot fi, în general, exhaustive. Jocul
de test este ales astfel încât rezultatele execuţiei programului să fie comparabile cu
rezultatele aşteptate conform specificaţiilor de funcţionare ale produsului (parţiale sau
globale). Scopul este de a pune în evidenţă eventualele erori. Testele pot să arate
prezenţa erorilor dar nu pot demonstra absenţa erorilor.
În construirea testelor se disting trei moduri de abordare a construcţiei jocurilor de test:
a)Abordarea aleatoare a testului
Testul este ales în mod aleator din domeniul de definiţie al datelor de intrare ale
programului. Domeniul de definiţie este stabilit pe baza specificaţiilor de interfaţă
operator-maşină ale programului (intrări-ieşiri).
b)Abordarea funcţională (sau a “cutiei negre”) :
Se iau în considerare numai specificaţiile privind funcţiunile programului (sau CE
trebuie să facă produsul). Specificaţiile trebuie să fie suficient de clare şi complete
pentru a permite verificarea fiecărei funcţiuni predefinite. Verificarea funcţională se
referă în special la date şi rezultate.
Verificare dinamică
c) Abordarea structurală (sau a “cutiei albe”):
In această formă, testarea se referă la structura internă a programului (modulului).
Se pot stabili mai multe criterii de aplicare a testului:
c1) Criteriul parcurgerii instrucţiunilor – jocul de test trebuie să arate că toate
instrucţiunile elementare sunt executate cel puţin o dată;
c2) Criteriul parcurgerii arcelor şi nodurilor grafului de control – graful de control
este o reţea care cuprinde structurile de control ale programului, cum ar fi spre
exemplu:

c3) Criteriul de parcurgere a drumurilor din graful de control;

c4) Criteriul de verificare a condiţiilor.
Verificare statică

Spre deosebire de verificarea dinamică, verificarea statică

are ca scop analiza proprietăţilor produsului, fără simularea
execuţiei programelor componente.
Sunt cunoscute două tipuri de tehnici de verificare statică:
tehnici informale şi tehnici formale. Aplicarea acestor tehnici
depinde de complexitatea produsului software analizat şi de
scopurile testării.
MODELAREA PROCESELOR
UTILIZAND UML
 Introducere
Concurenta din ce în ce mai puternică determină cresșterea calității bunurilor și
serviciilor oferite și reducerea timpului de procesare a comenzilor. Pentru atingerea
acestor obiective, companiile trebuie să-si optimizeze operațiunile interne.

Optimizarea= construirea unui model de afaceri care să reprezinte activitatea firmei,

permițand acesteia să analizeze și simuleze schimbările ce ar putea surveni.

Pana de curand, modelele utilizate erau cele ierarhice, ce reprezentau structura

organizatională a companiilor. În ultima vreme a devenit însă evident faptul că
optimizarea proceselor de afaceri reprezintă o soluție mult mai bună.

BPM: se referă la activitatea de reprezentare a proceselor ce au loc în cadrul unei

intreprinderi în scopul analizei acestora și identificării posibilităților de
îmbunătațire în viitor. În general aceste îmbunătățiri implică utilizarea unor soluții
informatice.

Procesul de afaceri: o colecție de activități interconectate și structurate care au ca

scop obținerea unui serviciu sau produs pentru un anumit client.
 Limbajul de Modelare Unificat
• Limbajul de Modelare Unificat (UML) : limbaj de modelare orientat obiect
considerat standard de către dezvoltatorii software din toată lumea.
• UML este succesorul propriu-zis al celor mai bune trei limbaje de modelare anterioare
orientate obiect (Booch, OMT, and OOSE) ce au fost unificate, obținandu-se astfel un
limbaj superior, mult mai expresiv.
• UML este un limbaj de reprezentare vizuală ce poate fi utilizat pentru: modelarea
proceselor de afaceri, reprezentarea structurii unei aplicații, descrierea arhitecturii
unui sistem, surprinderea comportamentului unui sistem, modelarea structurilor de
date sau pentru construirea unei specificatii detaliate a unui sistem.
Reprezentarea se face utilizand elementele standard ale UML: notațiile și
diagramele.
• Notațiile sunt elemente ce se regăsesc în cadrul fiecărei diagrame și sunt de tipul:
conectori, simboluri, valori etc.
• Diagramele sunt reprezentări ale unui proces, ale unui sistem sau ale părților lor
componente.
 Diagrame definite în UML
În cadrul UML sunt definite următoarele tipuri de diagrame ce se împart în
două categorii:

I Diagrame de structură
•Evidentiaza componentele ce trebuie să existe în cadrul sistemului modelat;
sunt în general folosite pentru documentarea arhitecturii sistemelor software.
II Diagrame de comportament
•Evidentiază ce trebuie să se întample în sistemul modelat; ilustrează
comportamentul sistemului și sunt utilizate în general pentru a descrie
funcționalitatea sa.
III Diagrame de interacțiune
•Diagramele de interacțiune reprezintă diagrame de comportament care
evidențiază modul în care circulă datele și se transferă controlul în sistemul
modelat.
 I. Diagrame de structură
• Diagrama de clasă: descrie structura unui sistem prin evidențierea
claselor din sistem, a atributelor lor și a relațiilor dintre clase;
• Diagrama de componente: descrie modul în care un sistem este
descompus în parțile sale componente și arată dependentele dintre
acestea;
• Diagrama structurii compozite: descrie structura internă a unei
clase și colaborările posibile datorate acestei structuri;
• Diagrama de construcție: descrie componentele hardware utilizate
în implementarea sistemului;
• Diagrama de obiecte: prezintă obiectele și relațiile dintre ele;
• Diagrama de pachet: descrie modul în care un sistem este împarțit
în grupuri logice aratand legaturile între aceste grupuri;
• Diagrama de profil: operează la nivel de metamodel.
 II. Diagrame de comportament

• Diagrama de activitate: descrie succesiunea de activități

operaționale ale componentelor unui sistem;
• Diagrama de stare: descrie stările și stările de tranziție ale
sistemului;
• Diagrama cazurilor de utilizare: descrie funcționalitatea oferită de
sistem din perspectiva actorilor, a scopurilor lor reprezentate ca și
cazuri de utilizare și a oricăror dependențe dintre aceste cazuri.
 III. Diagrame de interacțiune
• Diagrama de comunicare: arată interacțiunile dintre obiecte sau
componente dpdv al mesajelor. Reprezintă o combinație a
informațiilor preluate de la diagramele de clasă, de secventă și de
cazuri de utilizare ce descriu atat structura statică cat și pe cea
dinamică a unui sistem;
• Diagrama de interacțiune de ansamblu: conferă o privire de
ansamblu asupra sistemului, nodurile reprezentand diagrame de
interacțiune;
• Diagrama de secventă: arată modul în care obiectele comunică
între ele dpdv al secvențierii mesajelor;
• Diagrama de încadrare în timp: un tip specific de diagrame de
interacțiune în care focusul este dat de restricțiile de timp.
Diagrama cazurilor de utilizare (Use-case Diagram)
• Un use case este o reprezentare la nivel conceptual a unei interacțiuni dintre
un actor și un sistem și a activităților care se produc și pe care sistemul le face.
• Un caz de utilizare este o secvență a tranzactiilor realizate de sistem ca
răspuns la evenimentele declanșate de un actor sistemului.
• Un caz de utilizare conține toate evenimentele care pot surveni în cadrul
perechii actor - caz de utilizare, nu neapărat unul ce va apare în orice scenariu
particular.
• Un caz de utilizare poate de asemenea descrie comportamentul unui set de
obiecte, ca de exemplu o organizație.
• O diagramă use case este folosită în general pentru a indica sau caracteriza
funcționalitățile și comportamentul sistemului ce interactionează cu unul sau
mai mulți actori. Un actor poate fi un utilizator sau orice sistem ce poate
interacționa cu sistemul modelat.
• Atât timp ce actorii reprezintă utilizatorii, ei ajută la construirea unei imagini
clare a ceea ce se așteaptă a se întâmpla în sistem. Cazurile de utilizare sunt
construite pe baza nevoilor pe care le au actorii (utilizatorii). Aceasta asigură
faptul ca sistemul va produce ceea ce ș-a dorit.
 Diagrama cazurilor de utilizare
Element Descriere Notaţie

Un actor este, în principiu, un utilizator al sistemului, dar poate fi şi un

Actor
alt sistem informatic care interacţionează cu sistemul analizat.

Use Case-urile se reprezintă sub forma unei elipse în interiorul căreia

Use
este scris numele Use Case-ului respectiv. Numele incepe de obicei cu
Case
un verb
Asocierea este utilizată pentru a indica legătura dintre un Actor şi un
Asociere Use Case, în sensul că acel actor participă într-un fel oarecare în acel
Use Case.
 Diagrama Use case
• Ex. : un client care suna la 958 pentru Ora Exacta.
• Între actori şi use case-uri pot să existe relaţii de generalizare /
specializare atunci când un actor sau un use case poate fi asimilat
unei clase de actori, respectiv de use case-uri.
• O generalizare între două cazuri de utilizare indică faptul că, cazul
de utilizare poate împartăși comportamentul definit în unul sau mai
multe cazuri de utilizare.
• Ex. Emitere pasaport (temporar/ electronic)
• O generalizare între actori arată că un actor moștenește structura și
comportamentul ale unui actor sau mai mulți actori.
• EX. Studenți (Ciclul Licență/ Master)
 Relaţii între use case-uri

• Relaţia de tip extensie (şi implicit use case-urile de extensie)

se folosesc atunci când se modelează un comportament
opţional sau excepţional, care nu condiţionează finalitatea use
case-ului de bază.
Ex.: un cumpărător ce achiziționează un LCD poate să mearga la
bancul de probe pentru verificare.
• Relaţia de tip includere: se foloseşte atunci când use case-ul
inclus nu este o parte esenţială a fluxului din use case-ul de
bază sau este un comportament care se repetă în mai multe use
case-uri.
EX. Verificarea statusului unui colet și eventual schimbarea
destinației presupune în primul rand identificarea utilizatorului
 Diagrama Use case
Exercitiul 1: Să se realizeze diagrama de cazuri de utilizare
pentru o aplicaţie care simulează funcţionarea unui sistem de
rezervare online a biletelor de avion. În timpul unei sesiuni
de lucru se pot efectua următoarele operaţii:
- cautarea zborurilor
- efectuarea rezervării
- achiziționarea biletului
- verificarea statusului zborului
- anularea rezervării

iar opțional se poate alege locul în avion și reprograma

calatoria.
 Diagrama Use Case
Exercitiul 2: Să se realizeze diagrama use case pentru o aplicaţie care
simulează funcţionarea unui automat bancar. Deschiderea unei sesiuni
de lucru începe prin introducerea unui card în automat și verificarea
validităţii informaţiilor de pe card. În timpul unei sesiuni de lucru se
pot efectua următoarele operaţii:
- extragerea unei sume de bani dintr-un cont;
- afisarea soldului contului curent;
- transferul unei sume de bani din contul curent al cardului, la un alt
cont al clientului, aflat la aceeasi bancă;
- plata facturilor.

Opțional se poate tipări o chitanță cu soldul contului.

ATM-ul este verificat periodic pentru a funcționa corespunzător iar
zilnic este alimentat cu bani.
 Diagrame de clasa
• Class diagram este un tip de diagramă utilizată pentru descrierea
structurii statice, adică a entităţilor sau claselor existente într-un
sistem.

• utilizat de către dezvoltatori pentru specificarea claselor dar poate fi

foarte util şi pentru specificarea structurii unor sisteme sau
subsistem dintr-un business real.

• arată relațiile dintre clase de tipul: moștenire, agregare și asociere,

precum și operatiile și atributele aferente fiecăreia.

• Clasa are instanţe, sau realizări. Aceste instanţe sunt obiectele

clasei. Prin conceptul de clasă se descriu structura şi comportarea
obiectelor clasei. Structura conţine atributele fiecărui obiect din
clasă.
 Diagrama de clasă
Element Descriere Notaţie
O clasă este reprezentată printr-un dreptunghi cu trei
compartimente: în cel de sus se trece numele clasei, în mijloc
Clasă
se trec atributele clasei iar jos se trec operaţiile specifice
clasei.

Moştenirea este o relaţie care indică faptul că o clasă

Moştenire
moşteneşte caracteristicile unei clase părinte.

Asocierea este o relaţie generică între două clase. Aceste

Asociere relaţii pot fi de tipurile unu la unu, unu la mulţi, mulţi la
mulţi.

Atunci când o clasă depinde de o altă clasă, în sensul că

Dependenţă utilizează acea clasă ca şi atribut al său, se foloseşte relaţia
de dependenţă.

Agregarea indică o relaţie de tip întreg-parte (se poate spune

Agregare despre clasa părinte că are clase de tip copil). În această
relaţie, clasa copil poate exista şi fără clasa părinte.

Această relaţie derivă din agregare dar se utilizează atunci

Compoziţie când o clasă copil nu poate exista decât în cazul existenţei
clasei părinte.
 Diagrama de clasă
• În reprezentarea clasei atributele şi operaţiile sunt declarate în
compartimentele speciale:
– atributele: numele atributului: tipul atributului = valoare
implicită
– operaţiile: numele operaţiei (parametri): tipul valorii
returnate

• Se pot folosi tipurile de date specifice business-ului, ca de

exemplu: unități monetare, unități de timp, unități de greutate
etc.
Vizibilitatea: pentru a specifica vizibilitatea unui atribut sau a unei
operațiuni/metode, vom utiliza înaintea acestora urmatoarele notații:
+ Public – orice clasaăpoate avea acces la informație
# Protejat – numai clasa respectivă și succesorii săi pot accesa
informația
- Privat – numai clasa respectivă poate avea acces la informație.
Moştenirea este o relaţie prin care se indică faptul că o clasă copil moşteneşte
caracteristicile clasei părinte. În plus, clasa copil poate avea propriile
caracteristici.
Asocierea arată existenţa unei relaţii între clase. Asocierile de tip binar
(cu două capete) sunt reprezentate în mod obișnuit printr-o linie care
face legatura între două clase. Asocierile de ordin mai mare pot fi
reprezentate ca avand mai mult de două capete.
•O asociere poate primi un nume iar capete pot avea diverse roluri, grad
de multiplicitate, vizibilitate și alte proprietăți.

Ex. O universitate este condusă de un singur rector și un rector conduce o

singură universitate.

Ex. O universitate are mai multe facultăți.

Exemplu: între persoană şi card bancar putem avea următoarea relaţie:
o persoană poate avea zero, unul sau mai multe carduri.
Un tip special de asociere este indicat printr-o clasă de asociere. Ca și
clasele, asocierile pot avea atribute si operații. Pentru a arata grafic
acest lucru, o clasă de asociere se conectează printr-o linie intreruptă.
Altfel spus, relaţia în sine este o clasă.

Exemplu: relaţia de asociere dintre Banca și Persoana este intermediată

de existența unui card Bancar.
• Dependenţa indică faptul că o clasă depinde de altă clasă, în sensul
în care o modificare a celei de-a doua clase produce modificări în
clasa dependentă. Verbul folosit este „a utiliza”.
Agregarea indică faptul că o clasă părinte are elemente de tipul clasei
copil. Dacă în cazul asocierii utilizam verbul „a avea” pentru a exprima
legatura dintre două clase, în cazul agregării vom folosi verbul „a
conține”.
Exemplu: Catalogul poate avea mai multe Produse în acelaşi timp, un
Produs poate exista chiar şi daca acel catalog nu există.

•Într-o relaţie de tip compoziţie clasa copil nu poate exista decât

dacă există o instanţă a clasei părinte. O componentă nu poate
aparține decat unui singur întreg și dacă acesta dispare, în mod
automat dispare și componenta. Exemplu: instanța clasei Comisie
există atâta timp cât există instanţa clasei Examen.
Restrictii si note:
Restricțiile pot fi atasate sub forma de notă pe care o ancorăm de
asocierea careia îi aparține. Resțrictiile mai pot fi atașate
caracteristicii la care fac apel.

Exercitiu: Sa se realizeze diagrama de clase pentru o aplicație ce

simulează asignarea de proiecte în cadrul unei companii în care
avem următoarele clase: angajat, departament, proiect. Avem
următoarele două restricții:
– fiecare angajat poate lucra la mai multe proiecte cu condiția
ca proiectul să aparțină departamentului în care lucrează;
– bugetul proiectului nu trebuie să depașească bugetul
departamentului.
Cum identifici componentele necesare?
•verifica specificațiile: legislatia, standardele- vor ajuta la identificarea atributelor
și restricțiilor
•identifică lucrurile tangibile: ordin, factură, card, cec, inventar
•identifică roluri: client, manager, operator calculator
•identifică acțiuni: plasarea comenzii, anularea comenzii, încasarea banilor,
trimiterea comenzii
•Urmarește interacțiunile: dept. de vanzări primește comenzi de la clienți,

Substantivele folosite în descriere vor indica clase, atribute și obiecte

Verbele vor conduce la operații, metode și relații.

Din toate clasele identificate se vor opri clasele ce reprezintă obiecte fizice, entități
conceptuale, categorii de clase (ce vor deveni de fapt superclase) și clasele ce
reprezintă interfețe cu mediul exterior sistemului considerat.

Exercitiu: Identificați clasele componente ale unui sistem de tip hotel

 Diagrame de interactiune

• Permit specificarea în detaliu a modului în care obiectele

interacționează pentru a executa un task.
• Principala utilizare a acestor diagrame este de a ilustra modul
în care sistemul realizează un caz de utilizare sau un anumit
scenariu dintr-un caz de utilizare.
• UML furnizează două tipuri de diagrame de
interacțiune: diagrame de colaborare și diagrame de
secventă.
 Diagrame de colaborare

• Obiectele care interacționează pentru a executa un task împreună cu legăturile

dintre ele formează o colaborare.
 Diagrame de colaborare - continuare
Cuprinde următoarele componente:
· Obiecte: Reprezentate prin dreptunghiuri
(numeObiect:NumeClasa sau :NumeClasa).
· Legături: Reprezentate la fel ca asocierile dintre clase. Deoarece o legatură
este o instantă a unei asocieri, între clasele corespunzatoare oricăror două
obiecte care au o legatură trebuie să existe o asociere.
· Actori: Reprezentați la fel ca și în diagramele de cazuri de utilizare. În situația
în care colaborarea descrie realizarea unui caz de utilizare, actorii din colaborare
vor corespunde cu actorii din diagrama cazului de utilizare corespunzător. Pot
exista mai multi actori, însă numai unul singur va iniția cazul de utilizare.
· Mesaje: Numele mesajelor se reprezintă alături de liniile ce descriu legăturile
dintre obiecte, iar direcția de transmitere a mesajului este indicată printr-o
sageată (mesajul va fi transmis de la obiectul aflat la baza sageții către obiectul
aflat la varful săgeții).
Interacțiuni procedurale: după transmiterea unui mesaj, obiectul care trimite
mesajul asteaptă raspunsul înainte de a-și continua funcționarea.
· Un obiect începe să lucreze atunci cand primeste un mesaj; se spune ca în
acel moment obiectul este activat.
· În cele din urmă el trebuie sa trimită un raspuns celui care a trimis mesajul,
iar între timp el poate fie să lucreze, fie poate trimite mesaje altor obiecte pentru
a le face pe acestea să lucreze.
· Daca trimite un mesaj, el va fi în continuare activ, dar nu va putea sa
lucreze pana cand nu va primi răspunsul la acest mesaj: mesajul este sincron,
adică la transmitera unui mesaj se transmite controlul celui care primește
mesajul.
· Totul poate fi imaginat ca o stivă de activări, fiecare activare fiind asociată
cu un obiect care a primit un mesaj la care nu a raspuns încă.
· Mesajele sunt numerotate, folosind urmatoarea regula:
- Primul mesaj transmis de la un obiect la altul este numerotat cu 1,
următorul cu 2, etc.
- Cand un obiect a primește un mesaj, numărul acelui mesaj va fi folosit ca
prefix pentru toate mesajele trimise pana cand va raspunde la acest mesaj.
 Diagrame de secventă

• Un tip de diagramă de interacțiune care pune în evidență transmiterea mesajelor

de-a lungul timpului.
 Diagrame de secventa - continuare

Obiectele și actorii sunt reprezentați la capătul de sus al unor linii

punctate, care reprezintă linia de viață a obiectelor. Scurgerea
timpului este reprezentată în cadrul diagramei de sus în jos.
· Un mesaj se reprezintă printr-o sageată de la linia de viată a
obiectului care trimite mesajul la linia de viată a celui care-l
primește.
· Timpul cat un obiect este activat este reprezentat ca un
dreptunghi subțire care acoperă linia sa de viață.
· Opțional pot fi reprezentate răspunsurile la mesaje printr-o
linie punctată, dar acest lucru nu este necesar.
Crearea și distrugerea obiectelor

Diagramele de colaborare arată care obiecte sunt create și distruse în

timpul interacțiunii folosind stereotipurile « create » respectiv « destroy ».
Crearea și distrugerea obiectelor

Diagramele de secvență arată că un obiect este creat prin plasarea

acestuia în josul paginii, poziția sa corespunzand cu momentul în care a fost creat
obiectul. Distrugerea unui obiect este reprezentată printr-un X.
 Diagrama de componente
Diagramele de componente reprezintă relaţiile dintre componentele
sistemului descris. În cadrul UML, o componentă este considerată independentă şi
oferă altor componente acces la anumite funcţionalităţi prin intermediul unor
interfeţe. În mod uzual diagramele de componente sunt utilizate pentru descrierea la
nivel înalt a structurii sistemului.
Principalele elemente ale unei diagrame de componente sunt:
• Componenta – este reprezentată sub forma unui dreptunghi în interiorul căruia este
notat numele componentei;
• Interfaţa – o componentă oferă servicii altor componente prin intermediul unor
interfeţe. O interfaţă este reprezentată sub forma unui segment de dreaptă ce pleacă
din componentă şi se termină cu un cerc. O interfaţă a unei componente poate fi
echivalată cu o interfaţă de clasă – respectiv un set de funcţii pe care componenta le
pune la dispoziţie altor componente;
• Utilizator interfaţă – o componentă poate specifica faptul că necesită o anumită
interfaţă pentru a-şi desfăşura activitatea prin intermediul unei notaţii de tip
utilizator interfaţă. O astfel de notaţie este reprezentată sub forma unui segment de
dreaptă ce pleacă din componentă şi se termină cu un semicerc;
 Diagrama de componente-continuare

• Port – reprezentat sub forma unui dreptunghi mic amplasat pe graniţa componentei
şi reprezintă un punct de interacţiune prin intermediul căruia o componentă poate să
comunice cu alte componente.

O componentă expune un set de interfeţe ce reprezintă servicii pe care

aceasta le oferă sau pe care le utilizează. În figura următoare este exemplificată
diagrama de componente compusă din componentele Sensor ce implementează
interfaţa ISensorData şi componenta Controller ce utilizează interfaţa pusă la
dispoziţie de Sensor.
 Diagrama de componente-continuare

Între două componente pot fi reprezentate şi asocieri simple

reprezentate printr-o linie ce le uneşte. Aceste asocieri specifică o relaţie de
colaborare între două componente fără a intra în detalii cu privire la
interfeţele expuse sau cele folosite. Un exemplu de asociere între două
componente este prezentat în figura următoare.
 Diagrama de componente-continuare

O componentă poate fi formată la rândul ei din mai multe componente. În această

situaţie elementul componentă poate fi reprezentat având o dimensiune mai mare şi înăuntrul
ei fiind plasate alte componente ce fac parte din aceasta. În continuare este reprezentată
componenta CofeeMaker formată din componentele Heater, DosageUnit şi Controller ce
interacţionează.

În figură a fost introdusă şi notaţia de port. În sensul diagramelor UML portul este un
mecanism prin care o componentă internă a unei componente expune către exterior o serie de
funcţionalităţi ( de exemplu componenta Controller expune interfaţa IOrderProduct) sau prin
care o componentă internă accesează funcţii externe (de exemplu componenta Controller
utilizează interfaţa IPayment a unei entităţi externe). În mod uzual între o componentă internă
şi un port se realizează o asociere de tip delegat.
 Diagrama de componente-continuare

Pentru a specifica faptul că două componente comunică între ele prin intermediul
porturilor se poate realiza atât asociere directă între cele două porturi cât şi asociere prin
intermediul interfeţelor expuse de porturi. Un exemplu în acest sens este prezentat în
următoarea figură.

Diagrama de componente este o diagramă utilă, folosită de arhitectul de sistem în fazele

iniţiale de proiectare a sistemului pentru a evidenţia principalele componente software ale
acestuia şi modul în care acestea colaborează.
 Diagrama activitatilor
• Activity Diagram reprezintă o modalitate de modelare vizuală
a fluxurilor.

• Cu ajutorul activity diagram pot fi modelate foarte bine use

case-urile, dar, în aceeaşi măsură, aceste diagrame pot fi
folosite pentru modelarea proceselor de business (fără legătură
cu sistemul informatic).

• Notatiile sunt foarte asemănătoare cu cele din diagrama de

stare deoarece activity diagram nu sunt altceva decât o variaţie
a statechart diagram.
Element Descriere Notaţie
Prin activitate vom desemna întreaga activitate modelată
Activitate prin diagramă (formată dintr-o succesiune de acţiuni). -
Aceasta corespunde unui task de business.
Teoretic, acţiunile sunt numite activity states şi reprezintă
Acţiune o acţiuni desfăşurate în cadrul unui task, sau, privite altfel,
acţiuni ale unui obiect.
Reprezintă punctul de intrare în activitatea respectivă.
Stare iniţială Punctul iniţial este unic şi din el porneşte întotdeauna o
singură tranziţie.
Reprezintă punctul de ieşire din activitate. Pot fi mai
Stare finală
multe puncte de ieşire dintr-o activitate.
La încheierea unei acţiuni se trece întotdeauna la o altă
Tranziţie acţiune sau la starea finală. Tranziţia reprezintă trecerea
de la o acţiune la alta.
Printr-o decizie (sau punct de decizie) se modelează un
punct din cadrul fluxului unde se face o alegere, pe o
anumită ramură din flux. În acest caz tranzacţiile de ieşire
Decizie
trebuie să fie de tip condiţie. Aceeaşi notaţie se foloseşte
şi pentru reunirea fluxurilor după o decizie precedentă
(caz în care nu mai sunt necesare condiţiile).
Este un tip special de tranziţie, utilizată la fiecare dintre
Condiţie ieşirile posibile dintr-o decizie. Se marchează ca un text
(guard) pe săgeată şi arată condiţia care trebuie îndeplinită pentru
a urma acel flux.
Este folosită pentru cazurile în care anumite acţiuni se pot
desfăşura în paralel. Într-un asemenea punct poate avea
loc fie separarea fluxurilor, fie reunirea lor, după o
Bara de separare anterioară. Reunirea a două fluxuri înseamnă, de
sincronizare fapt, introducerea unei condiţii, prin care o activitate nu
poate începe decât după terminarea activităţilor finale din
fluxurile ce trebuie sincronizate (de aici termenul de
sincronizare).

Culoarele sunt reprezentări care permit separarea

Culoar
activităţilor din flux după criteriul responsabilităţii
(swimlane)
realizării activităţii.
• Punctele de decizie sunt puncte din fluxul de activităţi în care se
face o anumită alegere între mai multe variante posibile.
• Acţiunile paralele (asincrone) sunt acţiuni care pot desfăşura în
paralel. În viaţa reală, aceste acţiuni sunt acţiuni care nu depind una
de cealaltă. Paralelizarea acţiunilor se reprezintă pe diagramă în
felul următor:
• Această reprezentare ne arată că acţiunile „Verificare stoc” şi
„Verificare bonitate client” sunt declanşate de apariţia unei comenzi
de la client şi că aceste acţiuni sunt independenta între ele (începerea
uneia nu depinde de rezultatul celeilalte).
• Revenirea la fluxul unic (cu acţiuni sincronizate) se face în felul
următor:

• Această reprezentare ne arată că livrarea la client depinde de

finalizarea acţiunilor independente "Verificare stoc" şi
"Verificare bonitate client", astfel că acţiunea "Livrare la
client" nu poate începe decât după finalizarea ambelor acţiuni.
• Pentru a adăuga pe diagrame informaţia privind responsabilitatea
executării acţiunilor se folosesc elementele denumite swimlanes,
plasându-se fiecare acţiune pe "culoarul" actorului care execută acea
acţiune.
 Diagrama de stare
Diagramele de tip statechart sunt utilizate pentru a specifica posibilele stări prin care
poate trece un obiect şi modul în care se poate trece de la o stare la alta (modelare
work-flow-uri, modelare fluxuri de documente, diagrame de stări).
O stare reprezinta o etapa din comportamentul unui obiect; astfel, putem avea stari
initiale si stari finale.
– Starea initiala: cea in care se regaseste obiectul atunci cand a fost creat pentru
prima data;
– Starea finala: nu mai trece prin nicio tranzitie.

Trecerea de la o stare la alta este determinată de tranzacţiile intermediare - acestea

corespund Acţiunilor pe care le-am întâlnit la Activity Diagram (până la urmă,
Statechart Diagram reprezintă un alt mod de a vedea un flux ce poate fi modelat
exclusiv prin Activity Diagram, inventată pentru a exprima mai elocvent trecerile de
la o stare la alta).

Exemplu o comandă primită de la un client poate fi iniţial în stare de aşteptare, pentru

ca un operator să verifice bonitatea clientului şi stocul şi să accepte comanda. După
acceptare, se poate produce livrarea produselor comandate şi comanda trece în starea
de „comandă livrată” după care urmează facturarea şi închiderea comenzii.
 Diagrama de stare
Element Descriere Notaţie

Stare Indică starea în care se găseşte obiectul la un moment dat.

Stare Reprezintă punctul de intrare sau punctul în care obiectul

iniţială este iniţiat. Punctul iniţial este unic.
Stare Reprezintă punctul de final când starea obiectului nu se mai
finală modifică.
Tranziţia reprezintă trecerea de la o stare la alta, provocată
Tranziţie
de apariţia unui anumit eveniment.
Exemplu de folosire a
elementelor specifice
statechart diagram,
pentru cazul unei
comenzi: