Sintaxa şi semantica

limbajului de modelare UML

 Alfabet şi cuvinte
Alfabetul defineşte cele mai mici părţi ale limbajului; UML este alcătuit din
simboluri (dreptunghiuri, linii şi alte elemente grafice) şi din şiruri de caractere.
Cuvântul este cea mai mică unitate semantică de limbaj. Un cuvânt este un
grup format din elementele alfabetului, care are un înţeles.
În UML, cuvintele sunt grupate în două categorii mari:
• entităţi sau concepte – desemnează o serie de abstracţii şi sunt
reprezentate prin simboluri etichetate cu nume;
• relaţiile dintre entităţi – desemnează tipurile de legături care pot exista între
entităţi. Ele sunt reprezentate prin linii de legătură între simboluri şi au un
nume.
Cuvintele limbajului alcătuiesc vocabularul limbajului.
 Propoziţii şi paragrafe

Propoziţiile UML sunt fragmente de diagrame sau diagrame simple .

• O companie de asigurări are contract de asigurare cu o persoană.

• O persoană are un contract de asigurare cu o companie de asigurare.

Paragrafele UML se numesc diagrame.

Sintaxa limbajului UML implică diagrame.

!
Semantica limbajului UML se bazează pe paradigma orientării pe obiecte.
În UML, diagramele fac parte din două categorii:

• Diagrame statice sau structurale - descriu structura, responsabilităţile

sistemului informatic, componentele executabile ale sistemului, locaţiile
fizice de execuţie şi nodurile de stocare a datelor. Din această categorie,
fac parte diagrame ale claselor, ale obiectelor, ale cazurilor de utilizare,
ale componentelor şi diagrame de exploatare.

• Diagrame dinamice sau comportamentale – descriu comportamentul

şi interacţiunile dintre diverse entităţi ale sistemului informatic. Din
această categorie, fac parte diagramele de secvenţă, de colaborare, de
stare şi de activitate.
 A) Modelare structurală (modelare statică)

• Se referă la vizualizarea, la specificarea, la construirea şi la documentarea

aspectelor statice ale unui sistem, adică la relaţiile invariante dintre componentele
unui sistem. Din punct de vedere al modelării sistemelor orientate pe obiecte din
perspectiva UML, aspectele statice sunt: clasele şi relaţiile dintre clase,
interfeţele, topologia hard necesară execuţiei aplicaţiei.

A1) Diagrama claselor (Class Diagram)

• Descrie structura unui sistem în general. În componenţa ei intră clase,
stereotipuri şi relaţiile dintre acestea. Acest tip de diagrame este cel mai des
întâlnit în modelarea sistemelor orientate pe obiecte.

A2) Diagrama obiectelor (Object Diagram)

• Descrie structura unui sistem la un anumit moment. Acest tip de diagramă este
o variantă a diagramei claselor, care, în locul unei clase, prezintă mai multe
instanţe ale ei şi este formată din obiecte şi relaţiile (legăturile) dintre ele. Este
folosită în exemplificarea unei diagrame a claselor de complexitate mare,
permiţând vizualizări statice ale instanţelor actuale şi ale relaţiilor.
A3) Diagrama cazurilor de utilizare (Use Case Diagram)
• Descrie funcţionalitatea unui sistem.

• Prezintă actorii externi, cazurile de utilizare identificate numai din punct de

vedere al actorilor (comportamentul sistemului, aşa cum este perceput de
utilizatorii lui), nu şi din interior, precum şi relaţiile dintre actori şi cazurile de
utilizare.

• Un actor poate fi orice sau oricine interacţionează cu sistemul (trimite sau

recepţionează mesaje de la sistem sau schimbă informaţii cu acesta).

• Actorul are un rol în cadrul unui sistem, nu este un utilizator individual al

acestuia, şi din acest motiv, el este o entitate (o clasă), nu o instanţă. Un caz de
utilizare este iniţiat mereu de un actor şi furnizează o valoare actorului.

• Diagramele cazurilor de utilizare reflectă modul static de vizualizare a cazurilor

de utilizare asupra sistemului (diferite tipuri de relaţii între cazurile de utilizare), dar
şi modul de organizare şi de modelare a comportamentului unui sistem.
A4) Diagrama componentelor (Component Diagram)
• O diagramă a componentelor, cunoscută şi sub numele de diagramă de
implementare, descrie structura fizică a codului în termenii componentelor de
cod şi relaţiile dintre acestea.

• Acest tip de diagramă realizează o mapare de la view-ul static (logic) la view-ul

componentelor. O componentă poate să conţină un cod sursă sau să fie sub
formă binară sau executabilă. O componentă se mapează, de obicei, pe una sau
mai multe clase, interfeţe sau colaborări; din această cauză, diagrama
componentelor are legătură cu diagrama claselor.
• Diagramele de componente reflectă vederea statică de implementare asupra
sistemului.

5) Diagrama de desfăţurare (Deployment Diagram)

• Diagrama de desfăşurare indică arhitectura fizică pe care este implementat
sistemul, calculatoarele, device-urile (noduri ale sistemului) şi conexiunile dintre
ele.
 B) Modelare dinamică (modelare comportamentală)
B1) Diagrama de interacţiune (Interaction Diagram)
• Descrie interacţiunile în timp între obiecte, relaţiile şi mesajele care circulă
între acestea. Diagramele de interacţiune reflectă vederea dinamică de design şi
de proces.
• Pot fi: a) Diagrama de secvenţă
b) Diagrama de colaborare
a) Diagrama de secvenţă (Sequence Diagram)
- Prezintă colaborarea dinamică dintre un număr de obiecte, punând accentul pe
secvenţe de mesaje trimise între acestea pe măsura scurgerii timpului.
- Au două axe: timpul, pe axa verticală, şi setul de obiecte, pe axa orizontală.
a) Diagrama de colaborare (Collaboration Diagram)
- Este o diagramă de interacţiune, dar, pe lângă interacţiunea dintre obiecte
(schimbul de mesaje), prezintă şi obiectele şi legăturile dintre ele. Când trebuie să
decidem ce tip de diagramă trebuie folosit pentru a ilustra o interacţiune, avem în
vedere aspectul cel mai important de evidenţiat.

Obs. Se vor folosi diagramele de secvenţă dacă cel mai important aspect este
timpul sau secvenţa de mesaje şi vom folosi diagramele de colaborare când
trebuie evidenţiat contextul.
 B2) Diagrama de stare (State Diagram)
• Descrie ciclul de viaţă al unui element (al obiectelor, al subsistemelor şi al
sistemelor), prin specificarea stărilor în care se găseşte un element şi a
evenimentelor (mesaje, erori, condiţii care devin adevărate) care îi modifică starea
(tranziţie).
Obs. Este indicat să se construiască diagrame de stare numai pentru clasele din
sistem care au un număr de stări bine definit şi în care comportamentul clasei
este influenţat de acestea. Aceste diagrame intră în modurile de vizualizare design
şi de proces asupra sistemului.

B3) Diagrama de activitate (Activity Diagram)

• Prezintă activităţile şi responsabilităţile elementelor sistemului.
• Diagramele de activitate au ca elemente constitutive stări de acţiune (Action
States) şi mesaje care vor fi trimise sau recepţionate ca parte a acţiunii realizate.
• Reflectă vederea dinamică de design şi de proces şi sunt utilizate pentru
modelarea funcţiilor sistemului.
 Secţiuni (Views)
Secţiunile UML sunt perspectivele arhitecturale sau modurile de vizualizare
(arhitectural views). Din punct de vedere gramatical, ele sunt formate din mai
multe paragrafe.

Obs. Un model UML descrie ce trebuie să facă un sistem, nu cum să se

implementeze sistemul.

Secţiunile UML sau modurile de vizualizare sunt grupuri de diagrame care se

adresează unei anumite mulţimi de concepte (entităţi).

Modelul capturează cunoştinţe şi le comunică sub formă de mod de vizualizare

sau, pe scurt, “view” (arhitectural views).

Fiecare view focalizează atenţia echipei de realizatori asupra unui anumit tip de
probleme şi de aspecte privind subiectul tratat şi se adresează unei categorii
speciale de firme sau de instituţii.

Un sistem poate fi descris luând în considerare următoarele aspecte:

• funcţional - este descrisă structura statică şi comportamentul dinamic al sistemului;
• non-funcţional - necesarul de timp pentru dezvoltarea sistemului;
• organizatoric - organizarea lucrului, maparea modulelor de cod.
Elementele care construiesc un view se numesc elemente de vizualizare (view
elements).

Fiecare view este descris folosind un număr de diagrame care conţin informaţii
referitoare 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.
V1) Modul de vizualizare cazuri de utilizare
(The use-case or user view)

• Acest view surprinde funcţionalitatea sistemului, aşa cum este ea percepută de

actorii externi care interacţionează cu sistemul, precum şi de utilizatorii acestuia,
de diferiţi membri ai echipei realizatoare sau de alte sisteme.

• În componenţa lui intră diagramele cazurilor de utilizare pentru descrierea

statică a aspectului funcţional şi ocazional.

• Se pot folosi şi diagrame de activitate pentru a încapsula latura dinamică a

funcţionalităţii.

• Cei interesaţi de această perspectivă sunt clienţii, designerii, dezvoltatorii şi

cei care vor testa şi vor valida sistemul realizat.
V2) Modul de vizualizare structural sau logic sau design
(The structural or logic or design view)

• Se referă la cerinţele funcţionale ale acestuia, adică prezintă serviciile

asigurate de sistem utilizatorilor săi.

• Vizualizarea logică tratează din interior sistemul şi descrie atât structura internă
a acestuia, formată din clase, obiecte şi relaţii, cât şi colaborările care apar în
urma schimbului de mesaje între obiecte, pentru a realiza funcţionalitatea dorită.

• Structura statică este descrisă de diagramele de clasă şi de obiecte, care

includ elementele şi relaţiile care alcătuiesc sistemul.

• Pentru modelarea dinamicii sistemului, se vor folosi diagrame de stare, de

secvenţă, de colaborare sau de activitate.

• Cei care sunt interesaţi de acest tip de vizualizare a sistemului sunt designerii şi
dezvoltatorii.
V3) Modul de vizualizare componente sistem sau implementare
(The implementation or component view)
• View-ul componentelor se concentrează pe descrierea componentelor care
implementează sistemul, dependenţele care există între ele, resursele alocate
acestora, precum şi rezolvarea unor probleme legate de reutilizarea, portabilitatea
codului, informaţii administrative, cum ar fi un desfăşurător al muncii de
dezvoltare.
• Este folosit de dezvoltatorii sistemului, iar în componenţa sa intră diagramele de
componente, care descriu cum este implementat sistemul.

V4) Modul de vizualizare comportamental sau dinamic sau proces sau

concurenţă (The behavioral or dinamic or process or concurent view)
• Acest mod de vizualizare ia în considerare cerinţele de performanţă, de
fiabilitate, de utilitate, etc.
• Pentru descrierea comportamentului şi a dinamicii sistemului, se folosesc
diagramele de stare, de secvenţă, de colaborare şi de activitate.
• În reprezentarea acestui mod de vizualizare a sistemului, se folosesc şi
diagramele de implementare (ale componentelor).
• Cei interesaţi de o astfel de vizualizare a sistemului sunt dezvoltatorii şi
interogatorii de sistem.
V5) Modul de vizualizare desfăşurare sau mediu
(The deployment or environment view)
• În acest mod de vizualizare sunt surprinse desfăşurarea fizică a sistemului, ce
calculatoare şi ce tipuri de device-uri (noduri) vor fi folosite pentru implementarea
sistemului, cum sunt acestea conectate, precum şi ce componente (procese) se
vor executa în fiecare nod.
• Acest tip de vizualizare este reprezentat cu ajutorul unor diagrame de
desfăşurare, care indică modul de implementare a sistemului. În acest sens, ele
poartă etichete care specifică repartizarea pe tipuri de activitate şi informaţii
despre procesele executate în noduri.

• De acest tip de vizualizare sunt interesaţi dezvoltatorii, interogatorii de

sistem, precum şi cei care realizează testarea sistemului.
 Documente (Modele)

Un document este format dintr-un număr de secţiuni care descriu un subiect

comun şi pot fi cărţi, articole etc.

Documentele UML sunt modele. Un model este o reprezentare a unui sistem.

View-urile (secţiunile) sunt grupate formând modelul (documentul) arhitectural al
sistemului studiat.

Pentru paradigma de modelare UML, cel mai adecvat este modelul de dezvoltare
a sistemului dirijat de cazurile de utilizare, centrat pe arhitectură, iar abordarea
este iterativă sau cascadă.
 Pachete (Packages)

Un pachet reprezintă un mecanism de grupare a elementelor de modelare.

În UML, un pachet defineşte un mecanism de organizare a elementelor în grupuri

legate semantic. Rezultă că un element de modelare nu poate fi prins în mai
multe pachete, dar un pachet poate importa elemente de modelare din alte
pachete, iar după import le consideră ca şi când ar fi proprietatea lui.

Putem stabili relaţii între pachete, dar numai între tipuri, nu şi între instanţe
(pachetele nu au semantică definită de instanţe).

Un pachet poate să aibă vizibilitate, ca şi clasele, prin care se precizează

modalitatea prin care alte pachete pot să-i acceseze conţinutul.

Un pachet poate să aibă o interfaţă care îi redă comportamentul.

 Note (Notes)

O notă cuprinde ipotezele şi deciziile aplicate în timpul analizei şi al proiectării.

Notele sunt corespondentul comentariilor din limbajele de programare.

Notele pot conţine orice informaţie, inclusiv fragmente de cod sau referiri la alte
documente, şi se pot folosi în orice tip de diagrame. Ele se reprezintă printr-un
dreptunghi cu colţul dreapta sus îndoit, în interiorul căruia se află informaţia dorită.

Nota este ataşată unui element dintr-o diagramă printr-o linie punctată.
O notǎ poate să nu fie conectată, dacă aceasta se referă la întreaga diagramă.
 Stereotipuri (Stereotypes)

Stereotipul este un concept introdus în UML, care permite extinderea elementelor

de bază pentru a crea noi elemente.

Un stereotip reprezintă un înţeles specific asociat unui element. El se reprezintă

printr-un cuvânt între paranteze unghiulare duble (“<< >>”), scris deasupra sau
dedesubtul numelui elementului asociat.

Obs. Un stereotip transformă un element în altul cu un înţeles nou.

Exemplu. Dacă se ataşează stereotipul <<table>> clasei Examene, acesta va

reprezenta o bază de date tabelară.
 Proprietăţi

Proprietăţile sunt elemente de extindere UML, care lărgesc proprietăţile şi

semantica unui element UML.
Ele se reprezintă printr-o listă de şiruri de caractere între acolade ({ }), scrise
deasupra sau dedesubtul elementului UML.
Şirurile de caractere care reprezintă proprietăţile pot fi de două forme:
• valoare etichetată (tagged value) - se exprimă prin perechea "string = valoare"
şi reprezintă caracteristicile unui element şi valorile sale;
• constrângeri (constraints) - se exprimă în OCL (Object Constraint Language)
şi reprezintă condiţiile pe care trebuie să le satisfacă elementul.

Exemplu. valorile etichetate ale clasei EXAMENE sunt versiunea şi autorul, iar
constrângerea este perioada de examene.
Reprezentarea grafică a elementelor de modelare
Reprezentarea grafică a elementelor de modelare (continuare)
Reprezentarea grafică a elementelor de modelare (continuare)
Procese software

- introducere -
 Proces software

“Because software, like all capital, is embodied knowledge, and

because that knowledge is initially dispersed, tacit, latent, and
incomplete in large measure, software development is a social
learning process. The process is a dialogue in which the knowledge
that must become the software is brought together and embodied in
the software. The process provides interaction between users and
designers, between users and evolving tools, and between designers
and evolving tools [technology]. It is an iterative process in which the
evolving tool itself serves as the medium for communication, with each
new round of the dialogue eliciting more useful knowledge from the
people involved.”

Howard Baetjer, Jr.

Ce este procesul software?
O “hartă” a drumului ce trebuie urmat pentru construirea unui
produs sau sistem, de calitate crescută şi într-un timp dat.

Cine face procesul software?

Inginerii de sistem (software engineers) şi managerii lor; sunt
implicaţi şi cei cărora li se adresează.

De ce este important procesul software?

Deoarece dovedeşte stabilitate, control şi organizare.

Care sunt paşii?

Depind de software-ul pe care îl construim.

Care este produsul muncii?

În ochii inginerului de sistem produsul este format din programe,
documentaţie şi datele produse ca urmare a activităţii de inginerie
software definită de proces.
 Proces software – o tehnologie pe nivele

IEEE defineşte astfel Ingineria software:

(1) Aplicarea unei abordări sistematice, disciplinate, cuantificabile
asupra dezvoltării, punerii în funcţiune şi mentenanţei software-ului
(2) Studiul abordărilor de la (1).
Nivelul Proces: defineşte un cadru pentru o mulţime de zone cheie de
proces (key process areas). Aceste zone formează baza controlului
managementului proiectului software şi stabileşte contextul în care sunt
aplicate metodele tehnice, sunt obţinute produsele muncii (modele,
documente, date, rapoarte, forme etc.), sunt stabilite “pietrele de hotar”
(milestones), e asigurată calitatea şi se administrează potrivit schimbările.

Nivelul Metode: răspunde la întrebarea : Cum construim software-ul? şi

cuprinde un spectru larg de sarcini, care includ: analiza cerinţelor,
designul, construirea programului şi testarea. Metodele de inginerie
software includ activităţi de modelare şi alte tehnici descriptive.

Nivelul Instrumente: furnizează suport automat pentru proces şi metode.

Când instrumentele sunt integrate, astfel încât informaţiile create de un
instrument să fie folosite de altul, se creează CASE (Computer Aided
Software Engineering), care combină software, hardware şi o bază de
date a ingineriei software (ce conţine informaţii importante despre analiză,
design, construcţia programului şi testare).
 Modele de procese software

1) Modelul secvenţial liniar

2) Modelul prototipului (prototyping model)

3) Modelul RAD

4) Modele pentru procese software evolutive

a) Modelul incremental

b) Modelul spirală

c) Modelul spiral WINWIN

d) Modelul de dezvoltare concurentă

1) Modelul secvenţial liniar (cascadă)

Presupune activităţile:
i) Ingineria de sistem şi modelarea: stabilirea cerinţelor pentru elementele
sistemului
ii) Analiza cerinţelor software: trebuie înţelese comportarea software-ului,
interfaţa, performanţele dorite etc.
iii) Design: e de fapt un proces în mai mulţi paşi, ce se concentrează pe :
structura datelor, arhitectura software-ului, reprezentarea interfeţei şi
detaliul procedural (algoritmic).
iv) Generarea codului: care translatează design-ul în program.

v) Testarea: depistarea eventualelor erori (errors), defecte (faults) şi

eşecuri (failures)

Obs. Modelul cascadă e cel mai vechi; apar însă problemele:

• Proiectele reale urmează rar acest model
• E foarte dificil pentru client să stabilească cu exactitate cerinţele
• O versiune care să poate fi prezentată poate veni după mult timp
• Natura liniară a modelului poate conduce la stări de blocaj, când o
echipă implicată în proiect este nevoită să aştepte rezultatele altor
echipe

Obs. Modelul secvenţial liniar e cunoscut în literatură sub denumirea

classic life cycle.
2) Modelul prototipului
Adesea, un client defineşte o serie de obiective pentru software, dar nu
identifică în detaliu cerinţele de input, de procesare sau de ieşire. În alte
cazuri, dezvoltatorul poate să aibă îndolieli cu privire la eficienţa
algoritmului, adaptabilitatea la un SO sau la forma de interacţiune
om/calculator. Pentru aceste e indicat acest model.
Clientul şi dezvoltatorul se întâlnesc pentru a stabili obiectivele de
ansamblu şi a identifica oricare dintre cerinţele care sunt cunoscute şi
a stabili zonele unde e obligatorie definirea lor ulterioară.

Se conturează astfel un “quick design”, care se axează pe

reprezentarea acelor aspecte ale software-ului care care sunt vizibile
clientului (ex: ce anume se aşteaptă la input şi formatul output-ului).

Apare un prototip. Prototipul e evaluat de client şi folosit pentru a

rafina cerinţele.

Apare iteraţia, care pune în acord cerinţele clientului cu proiectul şi

ajută pe dezvoltator să înţeleagă mai bine ce se doreşte.
Ce facem cu prototipul dacă îndeplineşte condiţiile?

“In most projects, the first system built is barely usable. It may be too
slow, too big, awkward in use or all three. There is no alternative but to
start again, smarting but smarter, and build a redesigned version in
which these problems are solved . . . When a new system concept or
new technology is used, one has to build a system to throw away, for
even the best planning is not so omniscient as to get it right the first
time. The management question, therefore, is not whether to build a
pilot system and throw it away. You will do that. The only question is
whether to plan in advance to build a throwaway, or to promise to
deliver the throwaway to customers . . .” (Brooks, F., The Mythical Man-
Month, Addison-Wesley, 1975.)

Concluzie. Deşi pot apărea probleme, modelul prototipului poate fi

paradigma eficientă pentru ingineria software.
3) Modelul RAD
Rapid application development (RAD) e un model de proces de
dezvoltare software incrementală, care pune accentul pe ciclul de
dezvoltare extrem de scurt.
Modelul RAD e o adaptare “high-speed” a modelului secvenţial liniar.
Modelul RAD cuprinde următoarele etape:
i) Business modeling. Fluxul informaţiilor printre funcţiile business e
modelat într-un mod ce răspunde la întrebările:
• Ce informaţii conduc procesul de business?
• Ce informaţii sunt generate?
• Cine le generează?
• Unde se duc informaţiile?
• Cine le procesează?

ii) Data modeling. Fluxul informaţiilor ca parte a etapei de business

modeling sunt rafinate într-o mulţime de obiecte de date necesare
pentru a susţine business-ul.
iii) Process modeling. Obiectele de date obţinute în etapa anterioară
sunt transformate pentru a obţine fluxul de informaţii necesar pentru a
implementa o funcţie business. Descrierile de proces sunt create pentru
adăugarea, modificarea, ştergerea şi găsirea unui obiect de date.

iv) Generarea aplicaţiei. RAD presupune folosirea 4GT (fourth

generation technique). Procesul RAD lucrează pentru a refolosi
componentele existente ale programului (unde se poate) sau pentru a
crea componente reutilizabile.

v) Testarea şi predarea. Deoarece RAD încurajează reutilizarea

componentelor, multe dintre ele sunt deja testate, aşa încât timpul total
de testare este redus considerabil. Totuşi noile componente trebuie
testate şi toate interfeţele trebuie atent verificate.
Fiecare funcţie majoră e acoperită separat de o echipă şi apoi e
integrată în întreg.

Concluzii
• Pentru proiecte mari, dar scalabile, RAD necesită resurse umane
importante pentru a crea numărul corect de echipe RAD.

• RAD necesită dezvoltatori şi clienţi care se obligă la activităţi rapide

necesare pentru a obţine un sistem complet într-un timp redus

• Nu toate aplicaţiile sunt potrivite pentru RAD. Dacă un sistem nu poate

fi modularizat, construirea componentelor necesare pentru RAD devine
problematică.

• RAD nu e potrivit când riscurile tehnice sunt mari. Acest lucru apare
când o nouă aplicaţie foloseşte intens o nouă tehnologie sau când un
software nou cere un grad înalt de interoperabilitate cu programele
existente.
Business modeling
Scopul business process engineering (BPE) este să definească
arhitectura ce va permite business să utilizeze eficient informaţiile.
Se analizează şi se specifică Arhitectura datelor
design-ul pentru Arhitectura aplicaţiilor
Infrastructura tehnologică

1) Arhitectura datelor are ca blocuri constitutive obiectele de date (data

object). Un obiect de date conţine o mulţime de atribute care descriu un
anumit aspect, calitate, caracteristică a datelor ce sunt descrise.

Exemplu: obiectul Customer

O relaţie (relationship) indică cum sunt conectate obiectele unul cu altul.

Exemplu: pentru obiectele Customer şi produsA, o relaţie poate fi
cumpără.
2) Arhitectura aplicaţiei cuprinde acele elemente ale sistemului care
transformă obiectele în cadrul arhitecturii datelor pentru un anumit scop
de business.
3) Infrastructura tehnologică asigură fundaţia pentru arhitecturile datelor
şi aplicaţiei. Cuprinde hardware-ul şi software-ul care sunt folosite:
computere, SO, reţele, legături de telecomunicaţii, tehnologii de stocare
şi arhitectura (ex: client – server).
Pentru a modela arhitecturile descrise, se defineşte o ierarhie a
activităţilor ingineriei proceselor business.

World view e obţinută prin Information strategy planning (ISP). ISP vede
întreg întregul business ca o entitate şi izolează domeniile business-ului
(ex: inginerie, manufacturare, marketing etc.). ISP defineşte obiectele
de date care sunt vizibile la nivelul întreprinderii şi relaţiile dintre ele .
Domain view se obţine cu o activitate a BPE numită business area
analysis (BAA), care identifică în detaliu datele (sub forma tipurilor
entităţilor, adică a obiectelor de date) şi cerinţele funcţiilor (sub forma
proceselor) ale domeniilor de business în timpul ISP şi stabileşte
interacţiunile dintre ele.
Odată un information system izolat, BPE face o tranziţie spre ingineria
software. Invocând pasul business system design (BSD), sunt modelate
cerinţele de bază ale unui information system şi aceste cerinţe sunt translatate
în arhitectură de date şi de aplicaţie şi infrastructură tehnologică.
Data modeling
Răspunde la un set de întrebări specifice:
• Care sunt obiectele de date primare procesate iniţial de sistem?
• Care e compoziţia fiecărui obiect de date şi ce atribute descriu
obiectul?
• Unde “stau” în mod curent obiectele?
• Care sunt relaţiile dintre obiecte?
• Care sunt relaţiile dintre obiecte şi procesele care le transformă?
Apelează la diagrama relaţiilor dintre entităţi (ERD – Entity Relationship
Diagram)
4GT (Fourth Generation Techniques)
Termenul 4GT cuprinde o gamă largă de instrumente software care au
un lucru în comun: fiecare permite inginerului software să specifice
anumite caracteristici ale software-ului la un nivel înalt. Instrumentul
(tool) generează apoi automat cod sursă bazat pe specificaţiile
dezvoltatorului.

Paradigma 4GT pentru ingineria software pune accentul pe abilitatea de

a specifica software folosind forme de limbaj specializat sau notaţii
grafice ce descriu problema propusă spre rezolvare în termeni pe care
clientul poate să-i înţeleagă.

În mod curent, un mediu de dezvoltare software ce suportă paradigma

4GT include o parte dintre următoarele instrumente (tools):
• limbaje neprocedurale pentru interogările bazei de date;
• capabilităţi grafice de nivel înalt;
• capabilităţi de tip spreadsheet;
• generare automată a HTML şi a limbajelor similare folosite pentru
crearea site-urilor Web utilizând instrumente software avansate.
4GT (Fourth Generation Techniques) (continuare)

Concluzii privind paradigma 4GT:

1) Folosirea 4GT e o abordare viabilă pentru multe zone de aplicaţii.
Combinată cu alte instrumente CASE şi generatoare de cod, 4GT
reprezintă o soluţie de încredere pentru multe probleme software.

2) Folosind 4GT, timpul necesar pentru producerea software-ului e mult

redus pentru aplicaţii mici şi mijlocii şi de asemenea efortul pentru
design şi analiză pentru aplicaţiile mult e mult redus..

3) Folosirea 4GT pentru dezvoltarea unui software complex necesită la

fel de multă sau chiar mai multă muncă pentru analiză, design şi testări,
în ciuda timpului salvat obţinut din eliminarea codului.
4) Modele pentru procese software evolutive: sunt iterative, adică
permit dezvoltarea crescătoare a unor versiuni din ce în ce mai
complete ale software-ului.
a) Modelul incremental: combină elemente ale modelului cascadă
(aplicat repetat) cu filozofia iterativă a modelului prototipului.

Fiecare secvenţă liniară produce un “increment” livrabil al software-ului.

Exemplu : Software pentru editor de texte, poate livra managementul de
bază al fişierelor şi editarea la primul increment; editare mai sofisticată la
al doilea increment; spelling şi verificare gramaticală în al treilea increment
şi capabilităţi avansate de proiectare a paginii la al patrulea increment.
Obs. Primul increment e adesea un miez al produsului (core product),
adică cerinţele de bază sunt îndeplinite, dar mai multe capabilităţi (unele
cunoscute, altele necunoscute) rămân nepredate.
Acest core product e folosit de client. Ca rezultat al utilizării sau al
evaluării, se dezvoltă un plan pentru următorul increment, care stabileşte
modificarea core product-ului pentru îndeplinirea mai bună a cerinţelor
clientului şi furnizarea funcţionalităţilor adiţionale. Acest proces e repetat
după livrarea fiecărui increment, până se conturează întregul produs.
Concluzii.
• Modelul incremental e iterativ (ca şi modelul prototipului), dar se
concentrează pe livrarea unui produs operaţional la fiecare increment.
Versiunile iniţiale nu se regăsesc în produsul final, dar furnizează
capabilităţi nesecare utilizatorului.
• Modelul incremental e util când echipa de dezvoltatori nu e disponibilă
toată perioada. Core product-ul poate fi realizat cu mai puţini oameni.
b) Modelul spirală: combină natura prototipului cu aspectele sistematice
controlate ale modelului cascadă. Software-ul e dezvoltat într-o serie de
livrări incrementale. În timpul primelor iterări, livrarea poate fi un model pe
hârtie sau un prototip. În timpul iterărilor ulterioare, sunt produse versiuni
don ce în ce mai complexea sistemului.

Sunt între 3 şi 6 task regions într-un proiect tipic.

Cele 6 regiuni reprezentate în figură sunt:

• Comunicarea cu clientul: tasks pentru stabilirea unei comunicări efective

între dezvoltator şi client

• Planificarea: tasks pentru definirea resurselor, a planificărilor temporale

şi a altor informaţii în legătură cu proiectul

• Analiza riscurilor: tasks pentru stabilirea în egală măsură a riscurilor

ehnice şi manageriale

• Tehnologia (engineering): tasks pentru construirea uneia sau a mai

multor reprezentări ale aplicaţiei

• Construirea şi livrarea: tasks pentru construirea, testarea, instalarea şi

asigurarea suportului utilizatorului (ex: documentaţie şi training)

• Evaluarea clientului: tasks pentru obţinerea unui feed-back din partea

clientului, bazat pe evaluarea reprezentărilor software create în timpul
etapei de engineering şi implementate în timpul etapei de instalare
Echipa de dezvoltatori se mişcă în spirală în sensul acelor de ceasornic,
începând din centru.
Primul circuit în jurul spiralei ajută la dezvoltarea specificaţiilor produsului.

Următoarele circuite ajută la dezvoltarea prototipului şi apoi, progresiv, la

versiuni mai sofisticate ale software-ului.

Fiecare trecere prin dreptul zonei de planificare (planning region) produce

rezultate în ajustarea planului proiectului.

Costul şi planificarea temporală sunt ajustate pe baza feedback-ului

derivat din evaluarea clientului.

Managerul proiectului ajustează numărul de iteraţii necesare pentru a

completa software-ul.

Obs. Spre deosebire de modelele clasice, care se termină cu livrarea

software-ului, modelul spirală poate fi adaptat pentru a fi folosit pe
întreaga durată de viaţă a software-ului.
O privire alternativă asupra modelului spirală se obţine examinând axele
punctelor de intrare în proiect (project entry point axis).

Fiecare cub plasat de-a lungul axelor poate fi utilizat pentru a reprezenta
punctul de plecare pentru diferite tipuri de proiect.
Un “concept development project” porneşte de la miezul spiralei şi
continuă până ce devine completă dezvoltarea conceptului.
Concluzii
• Modelul spirală e o abordare potrivită pentru sistemele de mari
dimensiuni.
• Modelul spirală foloseşte prototipul ca un mecanism de reducere a
riscurilor dar, mai important, permite dezvoltatorului să aplice abordarea
prototipului la orice etapă din evoluţia proiectului.
• Modelul spirală menţine abordarea sugerată de ciclul de viaţă clasic, dar
o incorporează într-un cadru iterativ care reflectă mai realist lumea.
• Modelul spirală cere luarea în calcul a riscurilor tehnice în toate etapele
proiectului şi, dacă se aplică corect, ar trebui să reducă riscurile înainte să
devină problematice.
• Modelul spirală nu este folosit aşa cum se folosesc modelul liniar
secvenţial şi modelul prototipului.
c) Modelul WINWIN
“Eliciting software requirements demands negociation. Successful
negotiation occurs when both sides « win ».”

Stakeholder = cineva din organizaţie care are un interes de afaceri direct

în construirea sistemului sau produsului şi care va fi recompensat pentru
succes şi criticat pentru un eşec.

Modelul spiral al lui Boehm (Boehm, B., “Using the WINWIN Spiral Model: A
Case Study,” Computer, vol. 31, no. 7, July 1998, pp. 33–44) defineşte o serie
de activităţi de negociere la începutul fiecărei treceri în jurul spiralei:
1. Identificarea stakeholders ai sistemului sau subsistemului.

2. Determinarea condiţiilor de câştig (“win conditions”) ale stakeholders.

3. Negocierea acestor condiţii pentru a le reconcilia într-un set de condiţii

win-win pentru toţi cei implicaţi (inclusiv pentru echipa proiectului
software).
În afară de cele 3 activităţi de negociere menţionate, modelul spirală mai
introduce 3 anchor points:
• Life cycle objectives (LCO): defineşte un set de obiective pentru
fiecare activitate majoră de inginerie software.
• Life cycle architecture (LCA): defineşte obiectivele de trebuie
îndeplinite când se defineşte arhitectura software-ului.
• Initial operational capability (IOC): defineşte obiective în legătură cu
pregătirea pentru instalarea / distribuirea software-ului şi asistenţă.
d) Modelul de dezvoltare concurentă (numit şi concurrent engineering)
“Most software development process models are driven by time; the later it is,
the later in the development process you are. A concurrent process model is
driven by user needs, management decisions, and review results.” (Davis, A., P.
Sitaram, 1994)

Toate activităţile există concurent,

dar se găsesc în diferite stări.

Modelul concurent se foloseşte ca

paradigmă pentru dezvoltarea
aplicaţiilor client-server.
Concepţii şi principii
orientate-obiect
 CLASE, OBIECTE, INSTANŢE
O clasă descrie structura şi comportarea unei mulţimi de obiecte
similare.

Un obiect este o instanţă prezentă la rulare şi care alocă memorie

pentru varibilele instanţei; se comportă conform protocolului clasei sale.

Clasă (class) Obiect (Object)

«instance of»
Class Object
 ATRIBUTE, OPERAŢII, RESTRICŢII, RELAŢII
(Attributes, Operations, Constraints, Relationships)

Principiul încapsulării (encapsulation): Clasele combină atribute şi

operaţii într-o singură unitate. Atributele sunt accesibile doar prin
intermediul operaţiilor (adică indirect).

•Atribute: definesc structura obiectelor, i.e. componentele lor şi informaţia

sau datele conţinute în ele

•Operaţii: descriu comportarea (behaviour) obiectelor; se pot folosi

termenii servicii, metode sau (eronat) proceduri sau funcţii
•Restricţii: condiţiile, cerinţele şi regulile pe care obiectele trebuie să le
satisfacă
•Relaţii: de moştenire (inheritance), asociere şi de asemănare (like).
 Exemplu
Un cerc pe care vrem să-l reprezentăm are următoarele proprietăţi
(printre altele):
•Atribute: raza şi poziţia pe ecran (x,y).
•Operaţii: posibilitatea afişării, ştergerii, repoziţionării şi redimensionării.

•Restricţii: raza să fie strict pozitivă (r > 0).

•Relaţii: nu este cazul.

Numele clasei Restricţie

Numele atributelor
Valoare iniţială

Tip de atribut Parametri

Operaţii (Nume: tip=valoare iniţială)
Pe de o parte, în timpul analizei şi design-ului, clasele sunt modelate,
adică se iau în considerare proprietăţile şi relaţiile.

Pe de altă parte, diagramele use case şi altele sunt folosite pentru a

reprezenta interacţiunea dintre clase şi să simuleze procesele
selectate. În loc de clase, aceste diagrame folosesc obiecte, care se
reprezintă precum clasele (doar că sunt subliniate), cu posibilitatea
de a introduce valori pentru atribute.

Numele instanţei Numele clasei

Numele atributelor Valori ale atributelor

 Identitatea obiectelor

Principiul identităţii obiectelor: Fiecare obiect e prin definiţie unic diferit

de toate celelalte obiecte, independent de valorile concrete ale atributelor
sale.
 Principiul coerenţei

Principiul coerenţei: Fiecare clasă trebuie să fie responsabilă pentru

(exact) un aspect (logic) al întregului sistem. Proprietăţile situate în
această arie de responsabilităţi trebuie grupate într-o singură clasă şi nu
disipate în mai multe clase. Mai mult, o clasă nu trebuie să conţină
proprietăţi care nu sunt în aria ei de responsabilitate.

Responsabilităţile trebuie formulate succint şi în modul general.

 Taxonomie şi moştenire (inheritance)

Principiul moştenirii: Clasele pot reprezenta specializări ale altor clase,

i.e. clasele pot fi organizate ierarhic şi “moştenesc” (inherit) proprietăţi ale
claselor situate deasupra; la nevoie, pot fi suprascrise (overwrite), dar nu
eliminate.

Principiul substituţiei: Obiectele din subclase pot fi întotdeauna folosite

în locul obiectelor din supraclasa(e).

Moştenirea = reutilizarea proprietăţilor

Relaţia de moştenire e reprezentată printr-o săgeată, cu subclasa

punctând pe supraclasă.

Evitaţi moştenirea dacă aveţi alternative.

 Exemplu (moştenire simplă)

Obs. Operaţiile display(), remove()

trebuie să fie operaţii abstracte în
GeomFigure, doar în clasele Circle ... ele
devin operaţii concrete.
Obs. Operaţia setPosition() se poate
imple-menta in GeomFigure.

Clasa GeomFigure e o generalizare a clasei Circle, şi clasa Circle e o

specializare a clasei GeomFigure.
 Moştenire: restricţii şi probleme

Principiul responsabilităţii restricţiilor: O subclasă nu trebuie să

includă nici o restricţie asupra proprietăţilor supraclasei.
 Clase abstracte
Principiul claselor abstracte: Clasele pentru care nici o instanţă
concretă nu poate fi creată se numesc clase abstracte.

Instanţe
Clase
 Asocieri
O asociere e o relaţie între diferitele obiecte ale uneia sau ale mai multor
clase.

O asociere primeşte un nume şi o specificaţie numerică (cardinalitate)

care arată câte obiecte dintr-o parte a asocierii sunt asociate cu câte
obiecte din cealaltă parte.
Se pot adăuga şi nume de roluri, care descriu semnificaţia claselor.

Obs. Dacă nu e specificată direcţia în asociere, se consideră a fi o

asociere bidirecţională.
 Agregări
O agregare e o formă specială de asociere. Este tot o asociere între două
clase, cu observaţia că aceste clase se referă una la alta precum întregul
la părţile sale.

Un formă specială e cea în care părţile individuale depind de întreg pentru

existenţa lor; se numeşte compoziţie (composition)

Compoziţie

Agregare

Obs. Cel puţin la început, e permisă cardinalitatea 0 pentru un agregat.

 Agregări (continuare)
Într-o agregare, partea întregului e marcată cu un romb. Compoziţiile sunt marcate de un
romb plin şi au totdeauna o multiplicitate 1 (sau 0..1) de partea unde rombul e reprezentat.

1)

2)
 Schimb de mesage (Message Exchange)
Principiul schimbului de mesaje: Obiectele sunt unităţi independente
care cooperează şi interacţionează prin intermediul mesajelor pe care şi
le trimit unul altuia.

Un mesaj e reprezentat de numele operaţiei (cu argumente între

paranteze, dacă e cazul) şi o săgeată care arată sensul mesajului.

Obs. Un mesaj nu e o operaţie (adică, în sensul clasic, un apel de

procedură sau funcţie).
 Colecţii
Colecţiile sunt clase definite uzual în librăriile de clase standard şi au în
comun faptul că ele adună şi gestionează mulţimi de obiecte. Se mai
numesc şi clase container (container classes).

Colecţiile au toate operaţiile pentru adăugarea şi ştergerea obiectelor,

verificarea dacă un obiect dat e conţinut în mulţime şi determinarea a câte
obiecte sunt conţinute curent în mulţime.

Secvenţiale: obiectele sunt adunate într-o structură

Colecţii secvenţială - ex: tablou (array)
Asociative: păstrează obiectele, dar şi o cheie pentru fiecare
obiect prin intermediul căreia poate fi identificat - ex:dicţionar
 Polimorfism
Polimorfismul înseamnă că o operaţie se poate comporta diferit (în clase
diferite).
Polimorfism static: supraîncărcarea operatorilor, funcţii su signaturi
diferite
dinamic:o precondiţie este late binding

D.p.d.v. fizic, binding e punctul în viaţa unui program la care caller-ul unei
operaţii e dat de adresa de memorie a operaţiei. Uzual, se întâmplă la
compilare sau link-are. Acest tip de binding se numeşte early binding.
În late binding, locaţia de memorie a unei operaţii e determinată doar
când apelul are loc, i.e. atunci când mesajul corespunzător e trimis
obiectului. Prin urmare, asocierea între mesaj şi operaţie apare dinamic la
rulare, nu la compilare.
Moştenirea înseamnă că o clasă moşteneşte toate proprietăţile
supraclasei sale. Îi este permis totuşi să redefinească o operaţie
moştenită şi s-o rescrie cu o nouă definiţie. Care dintre aceste operaţii se
va folosi ca răspuns pentru un mesaj (adică din ce clasă vine operaţia
apelată) se decide doar la rulare.
Polimorfism dinamic (continuare)

În momentul în care mesajul display()

întâlneşte un obiect, decide ce opera-
ţie concretă va fi folosită: de exemplu,
pentru un dreptunghi, se va apela
Rectangle.display(). Se foloseşte
totdeauna operaţia din clasa cea mai
specializată. Acesta e principiul
polimorfismului (vezi figura de mai jos)

Cercuri şi dreptunghiuri
Paradigma OO

- completări -
 Clase
Numele claselor este, de obicei, un substantiv la singular, care trebuie
să fie cât mai sugestiv faţă de abstracţia modelată.

Atributele sunt de două feluri:

• atribute de instanţiere, care au valori specifice unui obiect particular;
• atribute de clasă, care au valori comune tuturor instanţelor clasei şi
se reprezintă subliniat

Atributele au următoarele tipuri:

• integer
• real
• boolean
• string
• enumerare
• boolean
• alte tipuri sau chiar clase
Sintaxa unui atribut va fi următoarea:
[vizibilitate] nume:tip_expresie [=valoarea_iniţială {listă de proprietăţi}]

Atributele clasei se pot clasifica după gradul de vizibilitate în:

-atribute publice, care sunt atribute vizibile, pot fi folosite şi în alte
clase şi sunt precedate de semnul "+"; mulţimea acestora se mai
numeşte şi interfaţă;
-atribute private (informaţionale), care pot fi accesate numai în clasa
respectivă şi care sunt precedate de semnul "-";
-atribute protejate, care pot fi accesate de clasa care le-a definit,
precum şi de generalizările sau de specializările ei, şi sunt precedate
de semnul "#".
Exemplu. Clasa Asigurări poate avea următoarele atribute:
 Mesaje şi metode
Obiectele nu sunt izolate, ele acţionează asupra altor obiecte şi/sau
permit să se acţioneze asupra lor. Relaţiile dintre obiecte se numesc
linkuri sau legături, iar comunicarea dintre obiecte se numeşte stimul.
Comportamentul se referă la modul în care un obiect reacţionează
(schimbă starea) la cererile altor obiecte din sistem, precum şi la modul
cum acţionează (trimite mesaje altor obiecte).

Un mesaj este o comunicare între clase via asocieri, aşa cum un stimul
este comunicarea dintre obiecte via legături.

Operaţia este abstractizarea unui mesaj care poate fi trimis clasei. La

primirea unui mesaj, o clasă execută o operaţie.
Sintaxa unei operaţii este:
[vizibilitate] nume_operaţie ([arg1 :tip1,............argn :tipn ] ): [tip]
public (+)
privat (-)
partajat (#)
 Mesaje şi metode (continuare)
Implementarea operaţiei se numeşte metodă, adică o metodă este o
unitate de cod, scris într-un limbaj de programare orientat pe obiecte.

Dacă, într-un limbaj de programare, se defineşte o funcţie şi se scrie

codul care determină ce trebuie să execute funcţia, atunci declaraţia
funcţiei este o operaţie, iar corpul funcţiei este o metodă.

Metodele se clasifică în:

a) Constructori - sunt metode care crează noi instanţe ale clasei. Unei
se aplică clase îi pot corespunde mai mulţi costructori.
numai
clasei
b) Destructori - sunt metode care elimină un obiect din memorie.

c) Selectori - sunt metode care accesează starea unui obiect fără a

o modifica.

d) Modificatori - sunt metode care schimbă starea obiectului.

 Mesaje şi metode (continuare)

Ceea ce obiectele ştiu şi pot să facă se numeşte caracteristică.

structurale
Caracteristicile sunt de două tipuri
comportamentale

Asocierile şi atributele alcătuiesc caracteristicile structurale (structural

features), deoarece ele indică structura clasei, similar cu modelarea
structurală, care indică structura modelului realizat

Operaţiile şi metodele sunt caracteristici dinamice (behavioral features),

deoarece comunică comportamentul clasei, asemănător cu modelarea
dinamică, folosită pentru a comunica comportamentul unui sistem
 Interfeţe
Mesajele primite de obiect pot fi:
• mesaje publice – mesaje care pot fi recepţionate de obiect, indiferent de
cine trimite mesajul;
• mesaje private – mesaje trimise obiectului de diferite părţi ale sistemului
sau chiar de el însuşi.

Interfaţa unui obiect cuprinde mesajele publice ale obiectului.

Obs. Obiectele din aceeaşi clasă au aceeaşi interfaţă, aşadar, interfaţa
unui obiect poate fi considerată ca o interfaţă a clasei.
Obs. Interfaţa conţine numai operaţiile, nu şi metodele (codul) care
implementează operaţiile.

Obs. În UML, interfeţele vor fi redate printr-un cerc, căruia i se ataşează

numele interfeţei.
Obs. Accesul către datele obiectului se poate face prin serviciile (operaţiile)
pe care acesta le oferă clienţilor săi. Aceste operaţii care găsesc şi setează
valorile atributelor se numesc getters şi setters. În acest caz, starea
obiectului este privată, în timp ce serviciile sale sunt publice.
 Clase abstracte
O clasă care are, cel puţin, o operaţie abstractă (operaţie pentru care nu e
dată decât signatura) se numeşte clasă abstractă.
Obs. O clasă abstractă nu poate fi instanţiată.

Obs. Clasa care moşteneşte o clasă abstractă va trebui să implementeze

operaţile abstracte din superclasă; în caz contrar, şi ea devine clasă
abstractă.
 Moştenire

Atributele şi operaţiile cu vizibilitate publică (precedate de '+') din

superclasă vor fi publice şi în subclasă, pe când cele private (precedate de
'-') vor fi moştenite în subclasă, dar nu vor fi accesibile acesteia. Atributele
şi operaţiile cu vizibilitate protejată (precedate de '#') nu pot fi accesate de
alte clase, ci numai de clasa respectivă şi de subclasele ei.

Când o clasă are o singură superclasă, spunem că există o moştenire

simplă.

Poate să existe şi o ierarhie de clase, adică o clasă să fie atât subclasă,

cât şi superclasă, şi, în acest caz, avem o moştenire multiplă.

Există mai multe scenarii de moştenire :

• adăugarea unor noi metode şi/sau stări subclasei;
• rescrierea unor metode din superclasă, din motive de eficienţă.
 Polimorfism

Polimorfismul constă în abilitatea de a folosi mai multe metode pentru o

operaţie (de exemplu: desenarea unei figuri sau calculul ariei).

Datorită polimorfismului, o subclasă poate să redefinească o operaţie

moştenită chiar dacă operaţia nu este abstractă în superclasă.

Implementarea unei operaţii va fi aleasă în funcţie de obiectul căruia i se

aplică operaţia. Se caută metoda întâi în clasa cea mai specializată a
obiectului; dacă aceasta nu se găseşte, se merge la superclasa imediat
următoare, până la găsirea ei în ierarhia de clase definită. Se constată
dacă există o clasă abstractă de bază, toate celelalte clase abstracte şi
concrete pot deriva din această clasă de bază.
Inginerie software

-generalităţi-
Ingineria software cuprinde metodele, instrumentele şi tehnicile folosite pentru
dezvoltarea software.
Software software de sistem: e software-ul care se comportă ca
instrument de ajutor pentru construcţia software-ului de aplicaţie.
Exemple: SO, baze de date, compilatoare etc.
software de aplicaţie: e software-ul care ajută să se efectueze
task-uri utile sau de recreere. Exemple: jocuri, ATM, software de
control în avioane, software pentru e-mail, editoare de texte etc.

In cadrul software-ului de aplicaţie, trebuie identificate categoriile de software:

• jocuri
• sisteme de informaţie – sisteme de stochează şi accesează o cantitate
mare de date (ex: sistem de rezervare a locurilor)
• sisteme în timp real, în care computerul trebuie să raspundă repede
(ex: controlul software al unei staţii de putere)
• sisteme încorporate (embedded systems), în care computerul joacă
un rol mai mic în cadrul unui sistem mai mare (ex: software într-un
celular)
• software de birou (office software): editor de texte, spreadsheets
• software ştiinţific: calcule, modelare, predicţie
Scopurile pe care dezvoltarea software caută sa le îndeplinească sunt:

a) satisfacerea cerinţelor utilizatorilor

b) cost redus de realizare a software-ului

c) performanţă înaltă

d) portabilitate

e) cost redus de mentenanţă

f) fiabilitate sporită

g) livrare la timp
a) Satisfacerea cerinţelor utilizatorilor
Principala problemă e analiza cerinţelor

Sarcina încercării de a asigura că software-ul face ce vor utilizatorii să facă se

numeşte validare.
b) Costul realizării software-ului

• Se estimează că în lume se cheltuieşte pentru producerea de software

aproximativ 1500 miliarde dolari şi că în fiecare an se prognozează o creştere a
acestei cifre cu 15%.
• Se estimează că productivitatea unui programator mediu este de 10-20 linii de
program pe zi, datorită următoarelor aspecte:

- un software de sistem se scrie mult mai greu decât un software de aplicaţie ;

- în studiul efectuat există mari diferenţe între programatorii individuali.
- această cifră include şi timpul petrecut pentru clarificarea problemelor, designul,
codul, testarea etc..

• Privire paralelă hardware - software

b) Costul realizării software-ului (continuare)

• Costuri relative în dezvoltarea software-ului

• Numărul relativ de erori facute în dezvoltarea software

• Costul relativ de reparare a diverselor erori

c) Performanţele software : trebuie să fim siguri că:
• un sistem interactiv răspunde într-un timp rezonabil de scurt
• un joc rulează suficient de repede pentru ca animaţia să nu fie supărătoare
• o anumită sarcină nu ia 15 ore în loc de una

Temă: Identificaţi sisteme software în care viteza e un factor important

Obs. Viteza mare şi economia de memorie sunt contradictorii

d) Portabilitate: cum pot transfera software de la un tip de computer la altul cu

minimum de efort

e) Mentenanţa: e termenul pentru efortul care trebuie pus în software, după ce

acesta a fost scris şi pus în aplicare.

de remediere (corectarea bug-urilor)

Mentenanţă
de adaptare (care modifică software-ul fie la
cererea utilizatorilor, fie la schimbarea SO etc.)
e) Mentenanţa (continuare)
Obs. Mentenanţa de remediere e practic inevitabilă, datorită faptului că testarea e
dificilă şi consumatoare de timp şi lasă cu siguranţă elemente de software cu bug-uri
Obs. Se estimează că mentenanţa reprezintă 67% din totalul timpului necesar
pentru dezvoltarea diferitelor părţi ale software-ului.
Exemplu de mentenanţă: Problema anului 2000. Ce tip de mentenanţă este?

f) Fiabilitatea
O parte a software-ului e fiabilă dacă lucrează fără să producă lucruri indezirabile.
Uzual se vorbeşte de bugs în software, dar pentru claritate se definesc si termenii:

• eroare (error) - o decizie greşită luată în timpul dezvoltării software;

• defect (fault) - o problemă care face ca software-ul să se îndepărteze de
comportarea dorită; poate să nu apară până când condiţiile nu sunt potrivite; e
sinonim cu bug.
• eşec (failure) – un eveniment care face ca software-ul să se îndepărteze de
comportarea dorită
f) Fiabilitatea (continuare)
• O eroare cauzează unul sau mai multe defecte.
• Un defect cauzează unul sau mai multe eşecuri.
• Eşecurile apar când sistemul este testat.

Obs. Îndepăratea bug-urilor şi încercarea de a asigura fiabilitatea se numeşte

verificare.

Obs. Deoarece este practic imposibil de îndepăratare a tuturor bug-urilor, s-a impus
conceptul de good enough software (software suficient de bun), adică lansarea
software-ului se produce când numărul şi severitatea defectelor (faults) devin
acceptabile

Obs. Există şi conceptul de zero defect software

Obs. Se estimează că hardware-ul “pică” de trei ori mai repede decât software-ul.
f) Fiabilitatea (continuare)
Sunt anumite aplicaţii care necesită o fiabilitate ridicată, safety-critical systems.
Exemple:
• sistemele pentru controlul avioanelor;
• controlul proceselor critice (software de comunicaţii ce joacă un rol critic în situaţiile
de urgenţă)
• controlul echipamentelor medicale

Temă. Identificaţi sisteme ce trebuie să fie fiabile şi altele care nu trebuie să fie.

g) Livrare la timp
E una dintre problemele majore, poate chiar principala problemă.

Se estimează că aproximativ 60% dintre proiecte depăşesc perioada de livrare şi

aproximativ 50% încalcă flagrant termenul de predare.
 Interacţiunea om-computer
În ultimul timp, multe interfeţe au devenit grafical user interfaces (GUIs) care
utilizează ferestre cu instrumente gen butoane şi bare de scroll. Se pune problema
designului acestor interfeţe grafice, care să fie simple şi uşor de utilizat.

Temă. Identificaţi sisteme care sunt mai greu de utilizat şi altele mai uşor de utilizat.

Scopuri conflictuale şi complementare

 Concluzii

Dezvoltarea software ridică probleme mari. Metodele şi instrumentele necesare

pentru îmbunătăţirea acestei situaţii sunt cunoscute ca inginerie software. Dintre
aceste idei, amintim:

• accent crescut pe realizarea sistematică a tuturor etapelor de dezvoltare

• realizare de instrumente software pentru dezvoltare
• accent crescut pe determinarea cât mai exactă a cerinţelor utilizatorilor
(requirements engineering şi validation)
• prezentarea unei versiuni prototip utilizatorilor
• folosirea unor limbaje de programare noi, inovatoare
Diagrame de clasă

- exemple -
 Temă. Modelaţi enunţurile următoare (îndeplinite simultan) :

1) Fişierele, shortcut-urile şi directoarele sunt conţinute în

directoare şi au un nume;

2) Un shortcut implică (se refera la) un fişier sau un director;

3) Într-un anumit director, un nume poate identifica doar un

element (fişier, shortcut sau director);
1) Fişierele, shortcut-urile şi directoarele sunt conţinute în
directoare şi au un nume;

Conceptele de fisier, shortcut, director trebuie modelate în clase.

Din moment ce un fişier, shortcut sau director nu poate fi inclus decât

într-un director (în alte directoare pot fi eventual copii ale acestora), iar
odată cu dispariţia directorului părinte dispar şi fişierele, shortcut-urile şi
(sub)directoarele conţinute în el, relaţia dintre clasele Fisier, Shortcut,
Director cu clasa Director trebuie să fie compunere.
2) Un shortcut implică un fişier sau un director;

Obs. Asocierea exclusivă sau asocierea XOR este o constrângere a două

sau a mai multor asocieri şi specifică faptul că o clasă poate participa la
cel mult o asociere la un moment dat.
3) Într-un anumit director, un nume poate identifica doar un
element (fişier, shortcut sau director);

Asocierea calificată este folosită în relaţiile one-to-many şi many-to-many

şi indică modul în care va fi identificat un anumit element al părţii many a
unei asocieri. Un calificativ este un atribut al unei clase de asociere, care
trebuie să reducă multiplicitatea asocierii care a generat clasa de asociere.
Un calificativ este folosit ca un index pentru a găsi obiectele de la celălalt
capăt al unei asocieri.
 Prima viziune a modelului va arăta ca în figura de mai jos:

Obs. În această variantă, două fişiere sau shortcut-uri nu pot avea

acelaşi nume în interiorul unui director, dar un fisier si un shortcut
pot avea acelaşi nume.
Soluţia vine din propoziţia a 3-a:
3) Într-un anumit director, un nume poate identifica doar un element
(fişier, shortcut sau director);
Adăugând o supraclasă, Element, care să generalizeze clasele Fisier,
Shortcut şi Director, cele 3 compuneri se pot îmbina într-una singură.
În această soluţie:
• Director e “composite” în relaţie cu Element
• Director e subclasă a clasei Element
Ce este pattern-ul “composite”?
E o soluţie elegantă pentru a modela ierarhii de elemente/compuneri.
Designerul poate lucra cu obiecte individuale (frunze – leaves) şi cu
combinaţiile lor (composite) în acelaşi fel.
Diagrame de clasă

- exemple -
 Temă. Modelaţi enunţul : “O ţară are o capitală.”

Ţara va fi o clasă cu unul dintre atributele sale capitala. Această soluţie e

utilă doar dacă vrem să avem acces la numele capitalei unei ţări.

Eventual se pot completa, ulterior, alte atribute: nume, monedă, limba

etc.

Pe de altă parte, ce se întâmplă dacă vrem să adăugăm proprietăţi

conceptului de capitală, cum ar fi populaţie, suprafaţă etc.

Capitală va deveni clasă

Asocierea “are” poate fi o agregare sau compunere? Da, compunere.

Pe de altă parte, modelul de mai sus nu aminteşte, în vreun fel,

noţiunea de oraş: dacă o capitală nu mai e capitală (din diverse motive),
oraşul în sine nu dispare, ci doar statutul său de capitală.

Vom modela aşadar faptul că o capitală e un oraş cu un anumit rol.

Vom adăuga apoi o agregare multiplă între Tara şi Oras şi o restricţie
care să arate că o capitală e aleasă dintre oraşele unei tări.

Pentru că un oraş poate aparţine, în

De e e agregare şi nu compunere? cazul general, în timp, mai multor ţări.
Exemplu: Berlin
În final, dacă vrem să arătăm că o capitală e un oraş şi are proprietăţi
specifice oraşului, atunci putem face clasa Capitala ca o specializare a
clasei Oras.

Dependenţa <<refine>> indică faptul că multiplicitatea “1” din partea

clasei Tara în compunerea cu Capitala înlocuieşte mai puţin restrictiva
multiplicitate “1..*” din partea clasei Tara pentru oraşe.

Obs. Clasa Oras din figura de mai sus nu e o clasă abstractă

Diagrame de clasă

- exemple -
 Temă. Modelaţi enunţurile următoare (îndeplinite simultan) :

1) Fişierele, shortcut-urile şi directoarele sunt conţinute în

directoare şi au un nume;

2) Un shortcut implică (se refera la) un fişier sau un director;

3) Într-un anumit director, un nume poate identifica doar un

element (fişier, shortcut sau director);
1) Fişierele, shortcut-urile şi directoarele sunt conţinute în
directoare şi au un nume;

Conceptele de fisier, shortcut, director trebuie modelate în clase.

Din moment ce un fişier, shortcut sau director nu poate fi inclus decât

într-un director (în alte directoare pot fi eventual copii ale acestora), iar
odată cu dispariţia directorului părinte dispar şi fişierele, shortcut-urile şi
(sub)directoarele conţinute în el, relaţia dintre clasele Fisier, Shortcut,
Director cu clasa Director trebuie să fie compunere.
2) Un shortcut implică un fişier sau un director;

Obs. Asocierea exclusivă sau asocierea XOR este o constrângere a două

sau a mai multor asocieri şi specifică faptul că o clasă poate participa la
cel mult o asociere la un moment dat.
3) Într-un anumit director, un nume poate identifica doar un
element (fişier, shortcut sau director);

Asocierea calificată este folosită în relaţiile one-to-many şi many-to-many

şi indică modul în care va fi identificat un anumit element al părţii many a
unei asocieri. Un calificativ este un atribut al unei clase de asociere, care
trebuie să reducă multiplicitatea asocierii care a generat clasa de asociere.
Un calificativ este folosit ca un index pentru a găsi obiectele de la celălalt
capăt al unei asocieri.
 Prima viziune a modelului va arăta ca în figura de mai jos:

Obs. În această variantă, două fişiere sau shortcut-uri nu pot avea

acelaşi nume în interiorul unui director, dar un fisier si un shortcut
pot avea acelaşi nume.
Soluţia vine din propoziţia a 3-a:
3) Într-un anumit director, un nume poate identifica doar un element
(fişier, shortcut sau director);
Adăugând o supraclasă, Element, care să generalizeze clasele Fisier,
Shortcut şi Director, cele 3 compuneri se pot îmbina într-una singură.
În această soluţie:
• Director e “composite” în relaţie cu Element
• Director e subclasă a clasei Element
Ce este pattern-ul “composite”?
E o soluţie elegantă pentru a modela ierarhii de elemente/compuneri.
Designerul poate lucra cu obiecte individuale (frunze – leaves) şi cu
combinaţiile lor (composite) în acelaşi fel.
Diagrame de clasă şi de
obiecte
- Concepte, exemple -
 Studiu de caz: Sistem de rezervare (booking) a biletelor de avion
pentru o agenţie de voiaj (varianta simplificată)

Cunoştinţele experţilor în fenomen se pot concretiza în propoziţiile:

 Pasul 1. Modelarea propoziţiilor 1 şi 2

Clase: AirlineCompany şi Flight

Obs. Se preferă multiplicitatea 1..* în loc de 0..*, pentru că se iau în

considerare doar companiile care oferă cel puţin un zbor.
Noţiunile open şi close sunt concepte dinamice. Ele privesc schimbările în
starea unui obiect Flight prin ordinul altui obiect AirlineCompany.

Se va insera un atribut state, de tip enumerare, ilustrat în figura de mai jos:

Obs1. Soluţia de mai sus nu e totuşi cea mai fericită. De aceea noţiunea de
stare (state) va fi modelată cu ajutorul diagramelor de stare (state
diagram).
Obs2. În diagramele de clasă, singurele elemente dinamice se realizează
prin intermediul operaţiilor.
 (continuare)

Mesajele vor circula între obiectele ce reprezintă instanţe ale claselor,

astfel:
 Pasul 2. Modelarea propoziţiilor 6, 7 şi 10

Obs. Se respectă principiul: “if we can ask an element for its value only, it
concerns a simple attribute; if several questions apply to it, though, an
object that possesses several attributes itself is involved, as well as links
with other objects”.
Obs. Deoarece noţiunea de airport e complexă şi implică nu doar un nume,
ci şi capacitate etc, e de preferat să se creeze clasa Airport decât
atributele DepartureAirport şi ArrivalAirport în clasa Flight.

Obs. E necesară restricţia {ordered} la clasa Airport, pentru a indica că

cele două aeroporturi legate zborului sunt ordonate (cel de sosire e după
cel de plecare).
 (continuare)

O soluţie tentantă ar fi să se creeze două subclase din clasa Airport:

Obs. Soluţia e incorectă, deoarece fiecare aeroport e un aeroport de

plecare pentru anumite zboruri şi aeroport de sosire pentru alte zboruri,
prin urmare clasele DepartureAirport şi ArrivalAirport au aceleaşi instanţe.
 (continuare)

Se va folosi noţiunea de rol, care se potriveşte perfect situaţiei:

Obs. Rămâne problema multiplicităţii în partea stângă a asocierii serves:
De câte aeroporturi e servit un oraş?

Obs. Dacă se consideră că verbul “a servi” se referă la mijlocul de

transport aerian care se găsesşte la cel mult 30 km de un oraş, atunci
multiplicitatea este 0..*, ca în figura de mai jos:
 Pasul 3. Modelarea propoziţiilor 8 şi 9

Obs. O escală (stopover) e în conexiune cu zborurile şi aeroporturile, deci

e indicat să se creeze o clasă Stopover:
Obs. O escală se produce într-un şi numai un aeroport şi un aeroport
poate fi folosit pentru mai multe escale.
Întrebare. O escală aparţine unui zbor şi numai unul ?
Răspuns. Nu, există contraexemple date de specialişti. Aşadar o escală
poate aparţine mai multor zboruri.

Pentru a completa diagrama, facem observaţiile:

• asocierea dintre Flight şi Stopover e o agregare, dar nu e compunere;
• escalele sunt ordonate conform cu zborurile
Obs. Clasa Stopover e strâns legată de clasa Airport (multiplicitate 1) şi
nu există ea însăşi, ci ca parte a clasei Flight.

O idee ar fi să considerăm clasa Stopover ca specializare a clasei Airport:

Obs. Nu e soluţia recomandată, din cauza aşa numitei “moşteniri de

implementare”.
Se poate folosi noţiunea de escală (stopover) ca al treilea rol jucat de un
aeroport cu privire la zboruri.

Obs. Clasa Stopover dispare, fiind înlocuită de o clasă de asociere, numită

StopoverInfo.
 Pasul 4. Modelarea propoziţiilor 3,4 şi 5

Obs. Trebuie să se facă distincţie între customer şi passenger (exemplu:

un client (customer) poate fi un angajat al celui care călătoreşte)
Obs. Din propoziţia 4, reies multiplicităţile: single flight, single passenger.
Obs. Propoziţia 5 poate fi îndeplinită prin adăugarea a două operaţii în
clasa Booking.
Obs. O soluţie mai simplă se obţine dacă vom considera pasagerul
(passenger) ca atribut în clasa Booking.

Obs. Totuşi, dacă vrem să gestionăm informaţii legate de pasager (cum ar

fi: adresa, numar telefom, e-mail etc) e mai recomandabil să folosim clasa
Passenger, cum am descris anterior.
 Revenim la:

Începutul propoziţiei e confuz, deoarece pare că implică direct un customer şi

flight. De aceea, pentru evitarea confuziei, propoziţia poate fi reformulată:

Obs. O rezervare (booking) este făcută de (doar) un customer şi acelaşi

zbor (flight) poate fi afectat de 0 sau mai multe rezervări.
Adăugând şi clasa Passenger, se pune întrebarea:
Câte rezervări poate să aibă un pasager?

Răspuns. La prima vedere, cel puţin una (altfel nu ar fi pasager).

Răspuns complet. E necesar să anticipăm că putem avea 0..*.
 Pasul 5. Adăugarea atributelor (attributes), restricţiilor
(constraints) şi calificatorilor (qualifiers)
Reluăm modelul preliminar obţinut până acum:
Pentru fiecare clasă, identificăm principalele atributele (folosind convenţiile
UML):
 Completăm modelul cu atribute derivate
Un atribut derivat (vezi Glosar de termeni) este o proprietate, interesantă
pentru analist, dar redundantă ca valoare, pentru că poate fi calculată din alte
elemente existente în model.
Exemplu: durata unui zbor (length), care se obţine ca diferenţă între
arrivalTime şi departureTime, ţinând cont (eventual) şi de arrivalDate şi
departureDate.
 Atribute derivate (continuare)

Cum convertim un atribut derivat într-o metodă de design?

Designer-ul are de ales între două metode:

• păstrează un atribut concret în design, care va avea metodele sale de acces
(set şi get); trebuie activat procesul de update ori de câte ori un item din
informaţie, de care depinde atributul, se modifică; - se foloseşte dacă e
necesar ca valoarea atributului derivat să fie prezentă în permanenţă sau dacă
se calculează greu;
• nu stochează valoarea redundantă, dar o calculează la cerere, folosind o
metodă publică; - se foloseşte dacă nu e cerut prea des sau dacă se poate
calcula cu uşurinţă
 Adăugarea restricţiilor (constraints) şi calificativilor (qualifiers)

Pentru a schimba un zbor (flight) sau client (customer), rezervarea

respectivă trebuie anulată şi creată una nouă.

Acest fapt se poate realiza folosind restricţia {frozen} pe asocierea potrivită.

(vezi Glosar de termeni)

Pe de altă parte, fiecare zbor e identificat în mod unic printr-un număr.

Putem să convertim atributul number (în clasa Flight) în calificativ (qualifier)
(vezi Glosar de termeni) al asocierii offers dintre clasele AirlineCompany şi
Flight.

Nu trebuie exagerat cu restricţiile. Se recomandă folosirea acelora care sunt

foarte importante, altfel diagrama poate deveni greu de urmărit.
 Pasul 6. Folosirea analysis pattern
Clasa Flight are mai multe responsabilităţi:

a) Prima priveşte toate informaţiile ce pot fi găsite în planificarea zborurilor

pentru fiecare companie aeriană: într-adevăr, există un zbor în fiecare luni,
să zicem, între oraşele A şi B, oferit de compania din oraşul A.
b) A doua se referă la informaţiile privind rezervările: cineva nu rezervă un
zbor A-B într-o zi de luni, ci rezervă un zbor A-B în ziua de 09.11.2009 (de
exemplu).
De aceea vom vedea un tip de relaţie de instanţiere dintre clasa
GenericFlight, care are responsabilităţile descrise la punctul a) şi clasa
Flight, care să aibă responsabilităţile de la punctul b).

În plus, să presupunem că o companie anulează nişte zboruri, din oraşul X,

din motive de modernizare a aeroportului, timp de câteva luni. În varianta
iniţială, trebuia să scăpăm de toate instanţele clasei Flight. La sfârşitul
lucrărilor, trebuiau recreate; în varianta a doua pur şi simplu instanţele
pentru zborurile ce pleacă din oraşul X nu vor exista.
Clasa Flight în versiunea iniţială
Separarea responsabilităţilor clasei Flight
Pentru updatarea modelului, trebuie:
• distribuirea atributelor, operaţiilor şi asocierilor clasei Flight între clasele
GenericFlight şi Flight;
• adăugarea unei asocieri “1-*” între clasele GenericFlight şi Flight;

În plus, adăugăm două atribute în clasa GenericFlight care să indice în ce zi

a săptămânii e planificat zborul şi în ce perioadă a anului are loc zborul
(validityPeriod).
E adăugată o restricţie care leagă valorile atributului departureDate din
clasei Flight şi din clasa GenericFlight
Obs. validityPeriod nu e un atribut simplu: putem fi interesaţi de începutul
perioadei, sfârşitul, durata etc. Soluţia ar fi crearea unei clase TimePeriod:

Trebuie adăugată o asociere între Flight şi AirlineCompany.

Distribuirea reponsabilităţilor între clasele GenericFlight şi Flight
 Metaclass pattern
Separarea responsabilităţilor poate fi generalizată în forma unui “analysis
pattern”, care poate reutilizat în alte ocazii.

Fie o clasă XX, cu multe responsabilităţi, care nu sunt prezente în fiecare

instanţă.

Adăugăm o clasă TypeXX, distribuim proprietăţile între aceste clase şi le

legăm într-o asociere de tipul “*-1”. TypeXX se numeşte metaclasă,
deoarece conţine informaţii ce descriu clasa XX.
 Pasul 7. Structurarea în pachete
Structurarea trebuie să ţină seama de două principii: coerenţa şi
independenţa.
Criteriile de coerenţă presupun a fi îndeplinite:
• obiective: clasele trebuie să returneze servicii de aceeaşi natură către
utilizatori;
• stabilitate: izolăm clasele care sunt stabile de cele care trebuie dezvoltate pe
parcursul proiectului
• durata de viaţă a obiectelor.

Independenţa presupune că divizarea în pachete trebuie făcută astfel încât

să fie minimizate dependenţele dintre pachete.

Propunem divizarea în două pachete:

• primul priveşte definirea zborurilor, foarte stabile (cele din GenericFlight)
• al doilea se refră la rezervări, împreuă cu toate asocierile lor
O soluţie posibilă:
 Pasul 8. Generalizarea şi reutilizarea
Se pune problema: putem reutiliza modelul de rezervare bilete pentru o
călătorie cu avionul la o problemă legată de rezervarea biletelor pentru o
călătorie cu autobuzul.
O călătorie cu autobuzul are un oraş de plecare şi un oraş de destinaţie,
respectiv timp şi dată de plecare şi destinaţie. Un client poate rezerva una
sau mai multe călătorii pentru unul sau mai mulţi pasageri.

Modelul va fi foarte asemănător cu modelul călătoriei cu avionul, dar puţin

mai simplu, datorat următoarelor aspecte:
• noţiunea de aeroport nu are echivalent, iar clasa City e direct asociată cu
clasa JourneyByBus;
• distincţia dintre GenericFlight şi Flight nu e transferabilă, deoarece
călătoriile cu autobuzul nu sunt aşa regulate şi nu sunt planificate în avans.
 Propunerea unei arhitecturi logice îmbinate
Urmărim obiectivele:
• izolarea claselor care sunt împărţite (shared) într-un nou pachet, pentru a fi
reutilizate
• factorizarea proprietăţilor împărţite într-o clasă abstractă.

Izolarea clasei City

Pe de altă parte, clasele Customer şi Passenger în ambele tipuri de
rezervare. De aceea, e bine să le izolăm într-un nou pachet, dar nu în
acelaşi (Geography), ci separat.

Există asemănare între pachetele FlightBookings şi BusBookings (singura

diferenţă fiind la clasele FlightBooking (redenumită pentru claritate din
Booking) şi BusBooking: au aceleaşi atribute şi aproape aceleaşi asocieri
Se va crea aşadar o supraclasă abstractă Bookings
Soluţia finală va fi următoarea:
 Glosar de termeni
Restricţii de schimbare (changeability):
• {frozen}: înseamnă că odată o valoare de atribut sau legătură inserată, nu
poate fi updatată sau ştearsă şi nu pot fi adăugate valori sau legături
atributului, respectiv asocierii;
• {addOnly}: înseamnă că deşi valoarea originală sau legătura originală nu
poate fi updatată sau ştearsă, alte valori sau legături pot fi adăugate atributului
sau asocierii (pentru instanţa obiectului cu restricţii); addOnly are efect doar
dacă multiplicitatea maximă a atributului / rolului asocierii depăşeşte
multiplicitatea minimă.

Asociere calificată (qualifier): este folosită în relaţiile one-to-many şi many-

to-many şi indică modul în care va fi identificat un anumit element al părţii
many a unei asocieri. Un calificativ este un atribut al unei clase de asociere,
care trebuie să reducă multiplicitatea asocierii care a generat clasa de
asociere. Un calificativ este folosit ca un index pentru a găsi obiectele de la
celălalt capăt al unei asocieri şi se reprezintă printr-un dreptunghi mic ataşat
clasei, unde un obiect al clasei, împreună cu valoarea calificativului, reduce
multiplicitatea la cealaltă extremitate a asocierii.

inapoi
 Glosar de termeni
Un element derivat, de exemplu atribute sau asocieri, este precedat de slash
”/”. Un atribut derivat nu va fi stocat în obiectele clasei, ci va fi calculat de
fiecare dată. Vezi figura de mai jos

Asocierea derivată mai poate fi reprezentată şi printr-o relaţie de dependenţă,

etichetată cu stereotipul <<derive>>.

inapoi
 Studiu de caz

-ATM (Automatic teller machine)-

 Enunţarea problemei
Se presupune că un ATM oferă următoarele servicii:
1) Distribuirea banilor către orice posesor de card (smartcard), prin intermediul
unui cititor de card
2) Consultarea soldului contului, facilităţi de plată şi de depozitare a cecurilor
pentru clienţii băncii (bank customers) care deţin un card (smardcard)
Trebuie avut în vedere că:
3) Toate tranzacţiile trebuie făcute în siguranţă
4) E necesar uneori ca bancomatul să se reumple etc.

De aceea, trebuie îndeplinite sarcinile: Obs. Enunţul problemei

• Să se identifice actorii poate fi incomplet (aşa
cum se întâmplă în
• Să se identifice cazurile de utilizare realitate)
• Să se construiască o diagramă use-case
• Să se descrie textual cazurile de utilizare
• Să se completeze descrierile cu diagrame dinamice
• Să se organizeze şi să se structureze cazurile de utilizare
 Pasul 1. Identificarea actorilor
1.1 Care sunt entităţile externe care interacţionează direct cu ATM-ul?
Prima propoziţie indică şi primul actor :
1) Distribuirea banilor către orice posesor de card (smardcard), prin
intermediul unui cititor de card
Atenţie! Cititorul de card face parte din ATM, deci nu poate fi actor!

Întrebare. Este cardul un actor (deoarece este extern ATM şi

interacţionează cu el)?
Răspuns. Poate fi, dar se aplică următorul principiu: eliminaţi actorii “fizici”
în dauna actorilor “logici”!, deoarece actorii reprezintă cineva sau ceva ce
beneficiază în urma utilizării sistemului.

Cardul nu beneficiază prin folosirea ATM, ci cel care deţine cardul, aşadar
cardul nu va fi considerat actor.
Aşadar, primul actor va fi posesorul de card (CardHolder)
 Pasul 1. Identificarea actorilor (continuare)

A doua propoziţie specifică :

2) Consultarea soldului contului, facilităţi de plată şi de depozitare a cecurilor
pentru clienţii băncii (bank customers) care deţin un card (smardcard)

Aşadar, se conturează şi alt actor: clientul băncii (bank customer)

A treia propoziţie specifică :

3) Toate tranzacţiile trebuie făcute în siguranţă
Cine oferă siguranţă?
În exemplul considerat (preluat după sistemul bancar din Franţa) se
identifică alţi doi actori:
• Visa authorisation system (VISA AS) pentru tranzacţii de retragere prin
intermediul unui smatcard Visa
• Sistemul informaţional al băncii (Bank IS) care să autorizeze toate
tranzacţiile făcute de un client prin intermediul smartcard-ului său, dar şi
accesarea soldului
 Pasul 1. Identificarea actorilor (continuare)

A patra propoziţie specifică :

4) E necesar uneori ca bancomatul să se reumple etc.

Aceasta sugerează că e nevoie activitate de mentenanţă: umplerea

bancomatului, recuperarea smartcard-urilor care au fost “înghiţite” etc.

Aceste sarcini identifică un alt actor: Operatorul (Maintenance Operator)

CardHolder
Bank Customer
Concluzie. Actorii sunt: Visa AS
Bank IS
Maintenance Operator
 Pasul 1 bis. Reprezentarea unei diagrame
Pentru o mai bună înţelegere a celor deduse la pasul 1, e mai utilă
desenarea unei diagrame, pe care o s-o numim diagramă statică de
context (static context diagram)
 Pasul 1 bis. Reprezentarea unei diagrame (continuare)
O altă soluţie, mai elaborată, ar fi să considerăm Bank customer ca
specializarea a lui CardHolder. Se rezolvă astfel problema excluderii
mutuale dintre cei doi actori.
 Pasul 2. Identificarea cazurilor de utilizare

Un caz de utilizare reprezintă specificarea unei secvenţe de acţiuni,

incluzând variante, pe care sistemul le poate efectua, interacţionând cu
actorii din sistem.
Vom lua actorii, unul câte unul, şi vom lista modurile în care aceştia
interacţionează cu sistemul:

1) CardHolder:
• retrage bani
2) Bank customer:
• retrage bani
• consultarea soldului
• depozitarea banilor (cash)
• depozitarea cecurilor
3) Maintenance operator:
• reumple cu bani bancomatul
• recuperarea cardurilor care au fost “înghiţite”
• recuperarea cecurilor care au fost depozitate

4) Visa AS:
• niciuna

5) Bank IS:
• niciuna

Actor primar sau secundar?

Numim actor primar pe acela pentru care cazul de utilizare produce un
rezultat observabil. Ceilalţi participanţi la cazul de utilizare se numesc
actori secundari.
Exemplu: Visa AS şi Bank IS sunt actori secundari. Nu pot ei înşişi să
folosească ATM.
 Pasul 3. Crearea diagramelor use case
O diagrama use case arată relaţiile dintre actori şi sistem, precum şi
cazurile de utilizare (use cases).

ATM

Retragere bani

Umple bancomatul
Consultare sold

Recuperează carduri
Depozitează bani

Frontiera Depozitează cecuri Recuperează cecuri

sistemului
 Pasul 3. Crearea diagramelor use case (continuare)
O variantă se obţine considerând Bank customer ca specializare a CardHolder.

ATM

Retragere bani

Umple bancomatul
Consultare sold

Recuperează carduri
Depozitează bani

Depozitează cecuri Recuperează cecuri

Obs. Vom redenumi actorul CardHolder în Visa CardHolder

 Pasul 3. Crearea diagramelor use case (continuare)
Adăugarea actorilor secundari
Recomandări:
• Implicit, rolul unui actor e “principal” (“primary”); dacă nu e aşa, indicaţi că
rolul e “secundar” (“secondary”) pe asociere, de partea actorului
• Pe cât e posibil, plasaţi actorii principali în stânga diagramei, iar pe cei
secundari în dreapta

Obs. Dacă actorul principal e Visa CardHolder, atunci Visa AS trebuie

solicitat; pe de altă parte, ATM va solicita Bank IS direct, dacă e vorba de
un client al băncii (bank customer).

O soluţie ar consta în adăugarea unei asocieri cu fiecare dintre aceşti actori

secundari.
Adăugarea unei asocieri cu fiecare dintre aceşti actori secundari.
O altă soluţie ar fi să se facă disticţie între cele două cazuri de utilizare
referitoare la retragerea banilor:
• Retragere bani cu Visa card
• Retragere bani cu un card bancar
 Pasul 4. Descrierea textuală a cazurilor de utilizare
Cazul de utilizare trebuie să aibă un început şi un sfârşit identificabile clar.
Trebuie specificate, de asemenea, variante posibile, cum ar fi scenariu de
succes, secvenţe alternative, în timp ce, simultan, se încearcă să se aranjeze
descrierile într-o ordine secvenţială, pentru a îmbunătăţi înţelegerea lor.

Scenarii
Numim fiecare unitate de descriere a secvenţelor de acţiune secvenţă.
Un scenariu reprezintă o succesiune particulară a secvenţelor, care e rulat de
la începutul la sfârşitul unui caz de utilizare.
Un scenariu poate fi folosit pentru a ilustra o interacţiune sau o execuţie a
unei instanţe a unui caz de utilizare.
 Pasul 4. Descrierea textuală a cazurilor de utilizare
(continuare)
Înregistrarea descrierii textuale nu e standardizată în UML. Se recomandă:

a) Rezumatul de identificare (Identification summary) (obligatoriu): include

titlu, rezumat, datele de creare şi modificare, versiunea, persoana
responsabilă, actorii...
b) Fluxul de evenimente (Flow of events) (obligatoriu): descrie principalul
scenariu de succes (main success scenario sau basic flow of events sau
normal path), secvenţele alternative şi secveţele de erori, precum şi
precondiţiile şi postcondiţiile.
c) Cerinţe UI (UI requirements) (opţional): adăugarea constrângerilor pentru
GUI.

d) Cerinţe nefuncţionale (Non-functional constraints) (opţional): se pot

adăuga informaţiile: frecvenţă, disponibilitate, acurateţe, integritate,
confidenţialitate, performanţă etc.
a) Rezumatul de identificare (Identification summary)

Titlu: Retragere bani folosind Visa card

Rezumat: Acest caz de utilizare permite unui posesor de card Visa (Visa
CardHolder), care nu e client al băncii, să retragă bani în limita zilnică.

Actori: Visa CardHolder (primary), Visa AS (secondary).

Creation date: xx/11/09

Date of update: zz/11/09

Version: 2.2

Person in charge: Nume Prenume

b) Fluxul evenimentelor (Flow of events)
Precondiţii:
• ATM e aprovizionat cu bani
• Nu e niciun card în cititorul de card
Main success scenario:
1. Visa CardHolder introduce cardul în cititor.
2. ATM verifică dacă este valabil cardul.
3. ATM cere Visa CardHolder pin-ul.
4. Visa CardHolder introduce pin-ul.
5. ATM verifică dacă datele sunt corecte.
6. ATM cere autorizaţie de la VISA authorisation system.
7. VISA authorisation system confirmă şi indică limita zilnică de retragere.
8. ATM cere Visa CardHolder să introducă suma dorită.
9. Visa CardHolder introduce suma dorită.
10. ATM verifică dacă suma e sub limita zilnică.
11. ATM întreabă Visa CardHolder dacă doreşte chitanţă.
12. Visa CardHolder cere chitanţa.
13. ATM returnează cardul către Visa CardHolder.
14. Visa CardHolder ia cardul.
15. ATM oferă banii şi chitanţa.
16. Visa CardHolder ia banii şi chitanţa.
O altă prezentare posibilă constă în separarea acţiunii actorilor şi sistemului:
1. Visa CardHolder introduce cardul 2. ATM verifică dacă este valabil cardul.
în cititor. 3. ATM cere Visa CardHolder pin-ul.

4. Visa CardHolder introduce pin-ul. 5. ATM verifică dacă datele sunt corecte.
6. ATM cere autorizaţie de la VISA
authorisation system.
7. VISA authorisation system 8. ATM cere Visa CardHolder să introducă
confirmă şi indică limita zilnică de suma dorită.
retragere.
9. Visa CardHolder introduce suma 10. ATM verifică dacă suma e sub limita
dorită. zilnică.
11. ATM întreabă Visa CardHolder dacă
doreşte chitanţă.
12. Visa CardHolder cere chitanţa. 13. ATM returnează cardul către Visa
CardHolder.

14. Visa CardHolder ia cardul. 15. ATM oferă banii şi chitanţa.

16. Visa CardHolder ia banii şi

chitanţa.
b) Fluxul evenimentelor (Flow of events) (continuare)
Secvenţe alternative:

A1) Număr de pin incorect: intervine la pasul 5

6. ATM informează CardHolder că pin-ul e incorect pentru prima şi a doua oară.
7. ATM înregistrează eşecul pentru card.
Scenariul se reîntoarce la pasul 3.

A2) Suma cerută e mai mare decât limita zilnică: intervine la pasul 10
11. ATM informează CardHolder că suma cerută e mai mare decât limita zilnică.
Scenariul se reîntoarce la pasul 8.

A3) Visa CardHolder nu vrea chitanţă: intervine la pasul 11

12. Visa CardHolder declină oferta de a primi o chitanţă.
13. ATM returnează cardul cătreVisa CardHolder.
14. Visa CardHolder ia cardul.
15. ATM oferă banii.
16. Visa CardHolder ia banii.
Secvenţe de erori:
E1) Card invalid: intervine la pasul 2
3. ATM informează Visa CardHolder că nu e valid cardul (nu se poate citi, expirat
etc.) şi îl confiscă, cazul de utilizare eşuează (fails).
E2) Număr de pin invalid după încercări repetate: intervine la pasul 5
6. ATM informează Visa CardHolder că pin-ul e incorect pentru a treia oară.
7. ATM confiscă (smart)cardul.
8. E notificat VISA AS; cazul de utilizare eşuează (fails).
E3) Retragere neautorizată: intervine la pasul 6
7. VISA AS interzice orice retragere.
8. ATM scoate cardul; cazul de utilizare eşuează (fails).
E4) Cardul nu e luat înapoi de Visa CardHolder: intervine la pasul 13
14. După 15 secunde, ATM confiscă (smart)cardul.
15. VISA AS e notificat; cazul de utilizare eşuează (fails).
E5) Banii nu sunt ridicaţi de Visa CardHolder: intervine la pasul 15
14. După 30 secunde, ATM ia banii înapoi.
15. VISA AS e notificat; cazul de utilizare eşuează (fails).

Postcondiţii:
• nu sunt prea evidente
c) Cerinţe UI (UI Requirements)
Mecanismul de intrare/ieşire disponibil pentru Visa CardHolder trebuie să fie:
• Un cititor de (smart)card.
• O tastatură numerică (pentru a introduce pin-ul) cu tastele “enter”, “corect” şi
“cancel”.
• Un ecran pe care să se afişeze mesajele ATM-ului.
• Taste în jurul ecranului, a.î. posesorul de card să selecteze suma dorită.
• Un distribuitor de chitanţe.
• Un distribuitor de bani.
d) Restricţii nefuncţionale (Non-functional constraints)
Timpul de răspuns:
• Interfaţa ATM trebuie să răspundă în limita maximă de 2 secunde.
• O tranzacţie nominală trebuie să se termine în cel mult 2 minute.
Disponibilitatea
• ATM trebuie să fie accesibil 24/7
• Lipsa hârtiei pentru tipărirea chitanţelor nu trebuie să fie un obstacol pentru un
posesor de card ră retragă bani.
Integritatea
• Interfaţa ATM trebuie să fie destul de robustă pentru a evita vandalizarea.
Confidenţialitatea
• Rata de eroare a procedurii de comparare a numărului de pin introdus cu acela de
pe card să fie sub 10-6.
 Pasul 5. Descrierea grafică a cazurilor de utilizare

Deşi descrierea textuală a cazurilor de utilizare e esenţială, are totuşi

dezavantajul că nu specifică în ce ordine vor fi secvenţele sau în ce
moment intervin actorii secundari.

E recomandat să completăm descrierea textuală cu una sau mai multe

diagrame UML mai dinamice.
Obs. Pentru cazurile de utilizare se recomandă diagramele de activitate (Activity
diagram), dar pot fi utile diagramele de secvenţe (Sequence diagram).

Obs. Pentru anumite scenarii se recomandă Sequence diagram, care se va numi

System sequence diagram, în care se reprezintă sistemul ca o cutie neagră,
actorul principal la stânga, iar actorii secundari în dreapta sistemului.
Crearea unei System
sequence diagram care
să descrie un main
success scenario pentru
cazul Retragere bani
folosind un Visa card.
 Activity state; Action state

O activity state modelează realizarea unei activităţi care:

• e complexă şi poate fi divizată în mai multe activităţi;
• poate fi întreruptă de un eveniment.

O action state modelează realizarea unei activităţi care:

• e simplă şi nu poate fi divizată;
• nu poate fi întreruptă de un eveniment.
Completarea diagramei de
secvenţe

Se introduc:
-activităţile principale ale
sistemului (prin mesajele
trimise către sistem);
-referinţe la secvenţele
alternative şi de eroare (prin
note).
 Organizarea cazurilor de utilizare
Identificarea părţii comune pe care cazurile de utilizare le au în comun şi
adăugarea relaţiei include.
Relaţia extend e opţională, spre deosebire de include, care e obligatorie.

Cazul de utilizare “Consultare sold” poate fi inserat în cazul de utilizare

“Retragere bani cu card bancar”, la punctul de extensie: verifica suma
Punctul de extensie trebuie declarat în descrierea textuală:
...
8. ATM cere Bank customer să introducă suma dorită.
Punct de extensie: Verifica suma.

9. Bank customer introduce suma.

 Identificarea unei relaţii de generalizare ce implică cazuri de utilizare

Considerăm cazurile de utilizare: Depunere cash şi Depunere cecuri. Ambele

implică aceiaşi actori: Bank customer ca actor principal şi Bank IS ca actor
secundar.
 Structurarea cazurilor de utilizare folosind pachete
Strategii posibile: gruparea după actor, după domeniu funcţional etc.
În acest exemplu, folosim gruparea după actorii principali
Crearea cazurilor de utilizare pentru pachetul Visa Withdrawal.
Crearea cazurilor de utilizare pentru pachetul Customer Transactions.
Crearea cazurilor de utilizare pentru pachetul Maintenance.
Diagrame de activitate
 Introducere

Diagramele de activitate descriu activităţile şi responsabilităţile elementelor

care alcătuiesc sistemul.

O diagramă de activitate reprezintă interacţiunile dintre activităţi, adică

fluxul de control al trecerii de la o activitate la alta.

Spre deosebire de diagrama de stare înfăţişează stările unui obiect şi

tranziţiile dintre ele, diagrama de activitate evidenţiază activităţile şi
tranziţiile dintre ele.

Diagramele de activitate pot fi folosite în următoarele scopuri:

- pentru a modela comportamentul intern al unei metode (implementarea
unei operaţii). Acesta este şi cel mai folosit caz când apelăm la acest tip de
diagramă;
- pentru analiza interacţiunii activităţilor unui caz de utilizare;
- pentru a ilustra modul de organizare a mai multor cazuri de utilizare şi
legăturile dintre acestea.
 Elementele unei diagrame de activităţi
O diagramă de activitate este o extensie a unei diagrame de stări.
Aceasta înseamnă că o diagramă de activitate va avea toate
caracteristicile unei diagrame de stare, plus unele noi.

Elementele componente ale unei diagrame de activitate sunt

următoarele:
1) stări de acţiune
2) tranziţii
3) bloc de decizii
4) linii de sincronizare
5) culoare
 1) Stări de acţiune şi stări de activitate

Prin activitate înţelegem o prelucrare (procesare) neatomică, în curs de

desfăşurare, în cadrul unei maşini de stare. Activităţile se pot descompune
şi nu sunt atomice, în sensul că pot fi întrerupte. Activităţile sunt alcătuite
din secvenţe de acţiuni, care sunt prelucrări atomice şi care au ca rezultat
schimbarea stării sau returnarea unei valori.
Există trei tipuri de acţiuni, şi anume: simple, iniţiale şi finale. O activitate
poate fi alcătuită dintr-o acţiune iniţială, una sau mai multe acţiuni simple şi
finale.

Reprezentare Activitate

O acţiune iniţială reprezintă prima acţiune într-o diagramă de stare. În UML,

o acţiune iniţială se reprezintă ca şi o stare iniţială, adică printr-un cerc plin.

O acţiune finală reprezintă ultima acţiune dintr-o diagramă de activitate. În

UML, o acţiune finală se reprezintă ca şi o stare finală, prin două cercuri
mici concentrice, din care cel interior este plin.
 2) Tranziţii

Tranziţiile sunt legăturile dintre acţiuni şi se reprezintă ca şi tranziţiile din

diagramele de stare, printr-o săgeată îndreptată spre acţiunea următoare.
În diagramele de activitate, tranziţiile nu sunt etichetate, deoarece ele
reprezintă încheierea activităţii respective. Tranziţiile pot, însă, să fie
etichetate cu condiţii, reprezentate printr-o afirmaţie scrisă între
paranteze drepte, care restricţionează tranziţia spre acţiunea următoare.

Există două tipuri de fluxuri de tranziţii:

a) fluxul de control;
b) fluxul obiectelor.
 a) Fluxul de control al tranziţiilor

Fluxul de control al tranziţiilor indică ordinea acţiunilor în secvenţă. Fluxul

tranziţiilor arată cum sunt ordonate acţiunile în secvenţă. Într-o diagramă de
activitate, activităţile sunt legate prin tranziţii automate, spre deosebire de
diagramele de stare, unde tranziţiile între stări sunt declanşate de
evenimente.

Atunci când o acţiune este încheiată, se va executa acţiunea specifică

ieşirii, dacă există, după care tranziţia este declanşată către următoarea
acţiune sau activitate. Urmează executarea acţiunii specifice intrării în noua
stare, dacă există şi executarea acţiunii sau a activităţii asociate noii stări,
etc.

Exemplu. Pentru un anumit sistem, aflat în starea de generare a

rapoartelor, avem următoarele activităţi:
- iniţială
- stabilirea criteriilor raportului
- generarea raportului
- tipărirea raportului
- finală
 b) Fluxul tranziţiilor obiectelor
O acţiune poate produce, modifica sau folosi obiecte. Aceste obiecte de
intrare sau de ieşire sunt conectate de acţiuni prin relaţii de dependenţă,
adică printr-o linie punctată între acţiune şi obiect.
Pentru o acţiune care foloseşte un obiect de intrare, tranziţia se reprezintă
printr-o linie punctată cu o săgeată îndreptată spre acţiune.
Pentru o acţiune care actualizează sau produce un obiect, tranziţia este
reprezentată printr-o săgeată punctată, de la acţiune la obiect.

Fig. Fluxul de control şi fluxul tranziţiei obiectelor

Fluxul de control al tranziţiilor se poate omite atunci când există un flux al
obiectelor care să indice ordinea acţiunilor, adică atunci când o acţiune
creează un obiect de ieşire, care să fie obiect de intrare pentru următoarea
acţiune din secvenţă.
 3) Bloc de decizii

O decizie reprezintă selectarea unui anumit flux de control al tranziţiilor,

din mai multe, în funcţie de o condiţie de gardă.

Într-o diagramă de activităţi, blocul deciziei este reprezentat printr-un

romb mic, în care intră o singură tranziţie, şi pot ieşi două sau mai multe
tranziţii.

Fiecare tranziţie de ieşire, este etichetată cu o condiţie de gardă, scrisă

între paranteze drepte, şi care indică condiţia care trebuie îndeplinită
pentru ca tranziţia să se producă. În cazul în care lipsesc condiţiile de
gardă, acestea sunt considerate, implicit, ca fiind false.
Exemplu. Să calculăm S= 0!+1!+2!+……+n! pentru n ∈ N, dat.
 4) Linii de sincronizare

Concurenţa (concurrency) implică faptul că mai multe tranziţii se petrec

simultan. În UML, sincronizarea între fluxurile de control se reprezintă cu
ajutorul barelor de sincronizare.

O bară de sincronizare permite îmbinarea (join) şi bifurcarea (fork)

ramificaţiilor paralele în interiorul unui fir de execuţie al unui caz de utilizare
sau al unei metode.

Tranziţiile care pleacă dintr-o bază de sincronizare se declanşează simultan.

Dacă mai multe tranziţii intră într-o bază de sincronizare, acestea trebuie să
se întâmple, înainte ca bara să fie trecută de una sau mai multe tranziţii de
ieşire din bara de sincronizare. Bara de sincronizare se reprezintă printr-o
linie îngroşată.

Dacă o bară are o singură tranziţie de intrare şi două sau mai multe de
ieşire, aceasta indică faptul că toate tranziţiile de ieşire se petrec o dată cu
tranziţia de intrare. Acest flux se numeşte splitting control.

Dacă o bară are mai multe intrări şi o singură ieşire, aceasta indică faptul că
toate intrările trebuie să se producă înainte să se producă tranziţia de ieşire.
Acest flux se numeşte synchronization control.
 5) Culoare

Deoarece o diagramă de activitate nu oferă indicii referitoare la elementul

care este responsabil pentru fiecare activitate, UML compensează această
slăbiciune, oferind tehnica culoarelor (swimlanes). Aceasta constă în
împărţirea unei diagrame de activitate în zone paralele, numite culoare de
activităţi (aşa cum o piscină este împărţită în culoare de nataţie) pentru a
evidenţia care element este responsabil pentru acţiunea din interiorul
fiecărei zone.

Fiecare responsabilitate este repartizată unei clase sau unei organizaţii şi

fiecare activitate este alocată unui culoar. Poziţia relativă a culoarelor nu
are nici o semnificaţie, tranziţiile fiind libere să traverseze culoarele la care
nu se referă.

În UML, culoarele se reprezintă prin regiuni verticale, paralele, separate prin

linii solide. Fiecare culoar are, în partea de sus, o etichetă care indică
elementul responsabil pentru acea activitate (o clasă, un actor sau un
departament al unei organizaţii).
Exemplu.
 Semnale
UML oferă două simboluri pentru semnale.
Primul simbol mesaj indică recepţionarea unui semnal. Numele semnalului
este trecut într-un pentagon concav (un dreptunghi cu o latură în formă de
triunghi concav). Recepţionarea unui semnal este reprezentată într-o
diagramă de activitate, printr-o relaţie de dependenţă de la obiectul care
trimite semnalul, la simbolul semnalului, urmată de o tranziţie de la
simbolul semnalului la următoarea acţiune.

Al doilea simbol semnal indică trimiterea unui semnal. Numele semnalului

este trecut într-un pentagon convex. Trimiterea unui semnal este
reprezentată într-o diagramă de activitate, printr-o relaţie de dependenţă de
la simbolul semnalului spre obiectul care primeşte semnalul.
 Exemplu de diagramă de activitate
Pentru exemplul discutat
anterior (vezi figura alăturată)
se adugă cerinţele:
- după realizarea unui raport,
se poate cere execuţia altuia;
- simultan cu generarea unui
raport se poate genera şi altă
operaţie (interogare,
actualizare, etc);
- un raport se listează la
imprimantă şi interogarea la
monitor;
- un raport şi o interogare pot
fi listate numai dacă
generarea a fost făcută cu
succes;
- se trimit semnale către
imprimantă şi monitor şi se
primesc semnale la
generatoarele de rapoarte şi
de interogări.
Diagrame de stare
 Introducere

O diagramă de stare poate fi ataşată oricărei clase care are stări bine
identificate şi un comportament complex. O diagramă de stare descrie o
istorie a vieţii obiectelor unei clase şi poate fi considerată un graf, bazată
pe stări conectate prin tranziţii.

Diagramele de stare specifică modul în care reacţionează un obiect la

primirea unui mesaj.

O diagramă de stare are o singură stare iniţială, una sau mai multe stări
simple, una sau mai multe stări finale şi tranziţii între stări.
 Elementele unei diagrame de stare

Elementele principale ale unei diagrame de stare sunt următoarele:

1) stări
2) tranziţii
3) evenimente
4) acţiuni

1) Stări
Starea acoperă toate proprietăţile statice ale unui obiect şi valorile
curente pentru fiecare proprietate. Toate instanţele unei clase există în
aceeaşi stare. Starea curentă a unui element se numeşte stare activă.

a) simplă
Stare b) iniţială
c) finală
a) Stare simplă: este o condiţie specială sau o situaţie a unui obiect de-a
lungul ciclului lui de viaţă.

Exemplu de stări de obiecte:

• obiectul bec poate avea stările: aprins şi stins;
• obiectul factură poate avea stările: plătit şi neplătit;
• obiectul lift poate avea stările: staţionează, urcă, coboară;
• obiectul calculator poate avea stările:
¾inactiv – calculatorul nu este pornit sau nu este accesibil
utilizatorilor;
¾activ – calculatorul este pornit şi este funcţional pentru utilizatorii
săi;
¾blocat – calculatorul nu este alimentat sau are unele erori majore.

Reprezentarea grafică a unei stări simple: dreptughi cu colţurile rotunjite

b) Stare iniţială: indică starea unui element şi momentul creării lui.
Există o singură stare iniţială. Se reprezintă, în UML, sub forma unui
cerc plin, de la care pleacă o săgeată.

c) Stare finală: indică starea unui element la sfârşitul vieţii sale, când el
este distrus. Într-o diagramă de stare, putem avea zero sau mai multe
stări finale. Se reprezintă, în UML, printr-un mic cerc plin, concentric
altui cerc gol, la care sosesc săgeţi de la stările sistemului, astfel:
2) Tranziţii
Tranziţiile sunt relaţiile dintre stări. O tranziţie reprezintă schimbarea
stării sursă a unui obiect, în urma unor acţiuni, datorită producerii unui
eveniment.
Tranziţiile dintre stări se produc în felul următor:
- un obiect este în stare sursă;
- se produce un eveniment (de exemplu recepţionarea unui mesaj);
- se execută o acţiune;
- obiectul intră în starea ţintă.

Într-o diagramă de stare pot exista:

- una sau mai multe tranziţii dintr-o stare, deoarece fiecare este declanşată
de un eveniment unic; în acest caz, spunem că există tranziţii cu mai
multe ţinte;
- din mai multe stări pleacă aceeaşi tranziţie, deoarece acelaşi eveniment
poate declanşa o tranziţie de la mai multe stări sursă; în acest caz, avem
tranziţia cu mai multe surse;
- tranziţie de la o stare la ea însăşi.
Tranziţiile se reprezintă, în UML, printr-o săgeată solidă, de la starea
sursă spre starea ţintă, etichetată cu numele evenimentului şi al acţiunii,
separată prin caracterul slash (‘/’), astfel:

Elementele etichetei sunt opţionale, dar nu poate exista numai acţiunea.

În cazul în care un eveniment cauzează o tranziţie fără acţiune asociată,
atunci trebuie să lipsească şi ‘/’ din eticheta unei tranziţii.

Uneori, o tranziţie se produce nu datorită unui eveniment, ci datorită

faptului că o stare completează o acţiune. În acest caz, tranziţiile fără
etichetă se numesc tranziţii automate (automatic transitions).
3) Evenimente

Un eveniment este ceva ce se produce asupra unui element. Cele mai

frecvente evenimente sunt mesajele recepţionate de un obiect.

În UML, un eveniment are următoarea sintaxă:

nume eveniment (listă parametri) [condiţia de gardă]
unde:
-nume eveniment – este, de obicei, acelaşi cu numele operaţiei
elementului care corespunde în diagrama de stare şi care se execută
pentru evenimentul respectiv (de exemplu, achitarea unei facturi,
pornirea unui calculator, etc);
-lista de parametri – este opţională şi conţine parametrii evenimentului
separaţi prin virgulă. Fiecare parametru poate fi o valoare explicită sau o
variabilă. Dacă evenimentul nu are parametri, se omit şi parantezele;
- condiţia de gardă – este, de asemenea, opţională şi indică o condiţie
care trebuie satisfăcută pentru ca o tranziţie să aibă loc. O condiţie poate
fi exprimată în limbaj natural, în limbaj de programare sau OCL.
În exemplul unui calculator, putem avea evenimentele următoare:
-Startup – indică faptul că un calculator trece din starea sursă, inactiv, în
starea ţintă, activ. Dacă calculatorul este parolat, atunci există parametrul
UserID. De asemenea, există posibilitatea ca un calculator să nu poată fi
pornit din anumite motive (pană de curent), atunci se impune condiţia de
gardă: dacă calculatorul poate fi pornit.
-Shutdown – indică faptul că un calculator, din starea activ, trece în starea
inactiv. Acest eveniment poate avea parametrul UserID. De asemenea,
există posibilitatea ca un calculator să nu poate fi închis din anumite
motive (de exemplu, nu au fost închise toate aplicaţiile), atunci se impune
condiţia de gardă: dacă calculatorul poate fi închis.
-Reset – indică faptul că respectivul calculator poate trece din starea
blocat în starea activ.
- Eroare Sistem – indică faptul că respectivul calculator are erori grave şi
trece din starea activ în starea blocat.
4) Acţiuni: reprezintă o prelucrare executată de un obiect aflat într-o stare
sursă, declanşată în urma producerii unui eveniment (de exemplu,
recepţionarea unui mesaj). O acţiune nu poate fi întreruptă de
evenimente.
În UML, o acţiune are următoarea sintaxă:
Valoare_returnată:= element_ţintă.nume_acţiune (listă argumente)
unde:
- Valoare_returnată – este opţională şi indică numele pentru valoarea
rezultată de acţiunea declanşată de un eveniment. Dacă se omite acest
câmp sau dacă acţiunea nu întoarce nici o valoare, atunci se vor omite şi
caracterele “:=”.
- Element_ţintă – este numele elementului care va executa acţiunea.
Dacă elementul care enunţă acţiunea este acelaşi cu elementul care
primeşte evenimentul declanşator al acţiunii respective, atunci acest câmp
se omite, împreună cu caracterul punct (‘.’).
- Nume acţiune – este, de obicei, acelaşi cu numele operaţiei elementului
respectiv sau al operaţiei elementului – ţintă, dacă acesta este specificat.
- Listă de argumente – este opţională şi indică parametrii care participă la
acţiune, separaţi prin virgulă. Fiecare parametru poate fi o variabilă sau o
valoare explicită.
variabilă
 Tipuri de evenimente şi acţiuni
În UML, există patru tipuri de evenimente: a)apeluri de operaţii;
b)semnale; c)schimbarea condiţiilor; d)scurgerea unui interval de timp.

a) Eveniment – apel de operaţie

Apelul de operaţie este un eveniment care, atunci când se produce,
determină schimbări în starea elementului care primeşte apelul.
Acest tip de eveniment este numit mesaj, se implementează, de obicei, ca
un mesaj sincron şi apare în eticheta unei tranziţii. Astfel, când un obiect
transmite un mesaj altui obiect (sau lui însuşi) şi invocă o operaţie,
controlul trece de la obiectul expeditor la obiectul destinatar. Obiectul
apelat execută tranziţia asociată evenimentului respectiv, îşi schimbă
starea şi transmite apelantului controlul. Apelurile de operaţii pot fi mesaje
asincrone, dacă limbajul care le implementează suportă calcul paralel.
b) Eveniment – semnal

Semnalul este un obiect expediat asincron de un obiect şi recepţionat de

alt obiect. Acest tip de eveniment se numeşte tot mesaj şi apare ca o
semnătură de eveniment într-o stare de tranziţie. Semnalul poate
declanşa o acţiune obiectului receptor într-o maşină de stare, în urma
căreia obiectul respectiv îşi schimbă starea, sau poate fi un mesaj
asincron într-o diagramă de interacţiune. Semnalele pot avea parametri,
care se scriu între paranteze rotunde.

Semnalele sunt definite ca un tip special de clasă, stereotipizate cu

<<signal>>. Aceste clase sunt folosite numai pentru trimiterea mesajelor,
nu pot avea operaţii, iar eventualii parametri ai semnalului sunt trecuţi în
compartimentul atributelor. Se poate construi o ierarhie de clase signal,
adică între semnale pot exista relaţii de generalizare, dar sunt excluse
orice relaţii cu clasele obişnuite.
Dacă o tranziţie are o semnătură de eveniment semnal, atunci toate
subsemnalele vor putea fi recepţionate prin acelaşi semnal, aşa cum este
ilustrat în figura de mai jos:
c) Eveniment – schimbare
Un eveniment schimbare reprezintă trecerea unui obiect în altă stare, în
funcţie de satisfacerea unei condiţii. Condiţia apare în condiţia de gardă a
semnăturii unei tranziţii. În UML, un astfel de eveniment este modelat cu
cuvântul cheie when, urmat de o expresie booleană. Se poate folosi o
expresie booleană pentru a indica o valoare (exemplu [when x=1]) sau
pentru testarea continuă a unei expresii (ca de exemplu, [when x<100]).

d) Eveniment – temporal
Un eveniment temporal este o întâmplare care depinde de scurgerea
timpului. El se reprezintă în UML prin cuvântul cheie after, urmat de un
interval de timp care reprezintă timpul scurs din momentul tranziţiei până
la schimbarea stării. Intervalul de timp poate fi redat în limbaj natural,
expresie de timp, sau în orice mod, dar trebuie să fie cât mai explicit.
Această combinaţie after+expresie_timp se trece în semnătura unei
tranziţii, la condiţia de gardă.

De exemplu, putem reprezenta evenimentele temporale, [after 5 secunde],

[after 2 secunde de la părăsirea stării], etc. Într-un eveniment temporal,
expresia din condiţia de gardă poate să nu fie precedată de cuvântul cheie
after (de exemplu, putem scrie [timp = timpdat], în loc de [after timpdat]).
 Activităţile stărilor
Pentru reprezentarea unei stări, se foloseşte tot dreptunghiul cu colţurile
rotunjite, compartimentat în trei zone:
- Compartimentul superior este dedicat numelui stării, care trebuie să fie
scris indiferent dacă dreptunghiul este compartimentat sau nu.
- În compartimentul din mijloc se scriu eventualele variabile de stare
(contori, date, constrângeri, etc.).
- În zona inferioară se trec activităţile, unde vor fi specificate
evenimentele şi acţiunile.
În cazul descrierii activităţilor, evenimentele şi acţiunile au aceeaşi sintaxă
ca şi în cazul tranziţiilor şi anume:
Nume eveniment (listă_parametri) [condiţie_gardă]
/element_ţintă.nume acţiune (listă_argumente)

Nume eveniment poate fi orice, dar, de obicei, există trei evenimente

standard care pot declanşa acţiuni stărilor, şi anume:
- entry – specifică acţiunea care se produce atunci când obiectul intră în
starea respectivă;
- exit – specifică acţiunea care se execută atunci când obiectul părăseşte
starea respectivă;
- do – specifică acţiunea care se execută atunci când obiectul se află în
starea respectivă.
Diagrame de stare

- Concepte şi exemple -
Studiu de caz: ceas cu alarmă
1. Putem seta alarma “pornit” sau “oprit”;
2. La timpul setat, alarma sună continuu;
3. Putem opri soneria.

Pasul 1. Desenarea unei diagrame de stare

Modelarea propoziţiei 1: Putem seta alarma “pornit” sau “oprit”
Modelarea propoziţiei 2: La timpul setat, alarma sună continuu

Obs. Alarma trebuie să se oprească si singură, după trecerea unui

anumit interval de timp

O activitate în cadrul unei stări poate fi:

• “continuă”: se produce doar atunci când un eveniment are loc şi
face ca obiectul să iasă din stare;
• “finită”: poate fi oprită de un eveniment, dar se poate opri şi singură
după trecerea unui anumit interval de timp sau la îndeplinirea unei
condiţii.
În exemplul de faţă, se adaugă o activitate “Sună” în starea Sonerie şi o
tranziţie automată care să iasă din starea Sonerie. O astfel de tranziţie
se mai numeşte completion transition şi se reprezintă în UML fără nume
de eveniment sau cuvânt cheie.

Obs. Dacă se doreşte dezactivarea alarmei în timp ce sună, va trebui

adaugată o tranziţie din starea Sonerie în starea Oprită.
Desenarea diagramei statice de context extinse (extended static
context diagram).
Diagrame de stare

- Concepte şi exemple -
Studiu de caz: ceas digital

1. Modul curent e modul “Afişare”;

2. Când se apasă o dată butonul, ecranul trece în “schimbă ora”. Se
poate schimba ora (prin incrementare cu 1) prin apăsarea repetată a
butonului de Avans;
3. Dacă apăsaţi butonul de mod din nou, ecranul trece în “schimbare
minute”. Apăsând butonul Avans repetat, se modifică minutele cu o
unitate.
4. Apăsând încă o dată butonul Mod, ceasul trece în “Afişare”.
Desenarea diagramei de stare

Obs. În starea Afişare, e posibil să fie apăsat butonul Avans, dar

apăsarea lui nu produce nici un eveniment, de aceea nu s-a mai
reprezentat.
Se consideră următoarea comportare: dacă se apasă lung butonul
Avans (mai mult de 2 secunde), incrementarea orei sau minutelor se
poate face mai repede

Cum poate fi modelat un asemenea comportament?

În exemplul de faţă, apăsarea butonului Avans o dată e echivalent cu

perechea «apasa» şi «eliberează». În condiţiile noului comportament,
se introduce evenimentul “eliberează buton” pentru a gestiona
eficient timpul de apăsare.

O primă soluţie ar fi inserarea unei condiţii asupra duratei de

apăsare, precum şi a unei noi stări, numite “Incrementare rapidă”
(vezi figura de pe pagina următoare).
Obs. Soluţia de mai sus e incorectă, pentru că apăsarea butonului nu
poate fi contorizată în timp (acţiunile sunt atomice).
Soluţii posibile:
• introducerea unei activităţi finite , “aşteaptă 2 sec”;
• folosirea cuvântului cheie «after».
Să presupunem acum că se introduc alte două facilităţi ceasului: buton de
lumină şi buton de alarmă.

În acest caz, avem 3 comportamente concurente:

1. controlul afisării;
2. controlul alarmei;
3. controlul luminii.
Le tratăm în ordinea simplităţii:
3. Controlul luminii

Obs. Controlul luminii poate fi modelat independent de controlul afişării şi

controlul alarmei.

1. Controlul alarmei se poate face ca în exemplul “Ceas cu alarmă”.

1. Controlul afişării depinde de stările de pînă acum, în sensul în care
putem modifica, prin apăsarea butonului Mod, şi timpul de declanşare a
alarmei (prin modificarea orei şi minutelor). De aceea, trebuie introduse 2
noi stări.
Să punem toate comportamentele împreună.
- O primă soluţie: prin intermediul unei diagrame de clasă
- A doua soluţie: arătând “regiunile concurente” din cadrul diagramei de stare. E
mai puţin folosită decât prima soluţie.
Diagrame de componente şi
de desfăşurare
 Diagrame de componente

O diagramă de componente prezintă dependenţele existente între

diverse componente software (cod sursă, cod binar, executabile, librării
cu legături dinamice-DLL, etc.) care compun un sistem software. Aceste
dependenţe sunt statice (au loc în etape de compilare sau link-editare)
sau dinamice (au loc în timpul execuţiei).

O componentă este o parte fizică dintr-un sistem, un lucru real, care

există pe un calculator. În UML, noţiunea de componentă poate să
desemneze atât un tip (o categorie) de obiecte, cât şi fiecare obiect din
tipul respectiv (instanţa tipului).

De exemplu, o aplicaţie executabilă este o componentă care reprezintă

un tip (o categorie), în timp ce o aplicaţie care se execută la un moment
dat, care are o identitate în momentul execuţiei, este o instanţă a acelui
tip.
Reprezentare

Exemplu
Relaţia dintre componente şi clase

Asemănări:
- Au un nume format dintr-un şir de caractere.
- Au instanţe, care au un nume separat prin “:” de numele clasei, respectiv
al componentei.
- Pot realiza interfeţe.
- Pot participa la relaţii de asociere, de generalizare, de dependenţă, de
realizare şi de agregare (clase sau componente incluse în alte clase,
respectiv componente).

Deosebiri:
- Clasele sunt abstracţii ale unui set de atribute şi de operaţii;
componentele sunt părţi fizice dintr-un sistem, rezidente într-un nod. Se
utilizează componente când modelăm un lucru rezident într-un nod; în
celelalte cazuri, folosim, în modelare, clase.
- Clasele au atribute şi operaţii, pe când componentele au numai operaţii,
accesibile numai prin intermediul interfeţelor lor.
- O componentă este implementarea fizică a uneia sau a mai multor entităţi
conceptuale, cum sunt clasele şi colaborările; între componente şi
implementările ei există o relaţie de dependenţă.
Componentele folosite în UML pot fi împărţite în trei categorii:
• Componente fundamentale (desfăşurare) – care formează baza
sistemelor executabile, ca de exemplu: executabile, DLL-uri, controale
ActiveX, JavaBeans, componente COM+, pagini WEB, tabelele bazelor
de date, etc.
• Componente create de utilizator – care sunt produse rezultate din
procesul de dezvoltare şi care formează componentele fundamentale, ca
de exemplu: fişiere cu codul sursă şi de date. Aceste componente sunt
folosite în crearea, în modificarea şi în dezvoltarea executabilelor.
• Componente de execuţie – create ca o consecinţă a folosirii unui sistem
executabil.
UML foloseşte şi stereotipuri standard:
• <<executable>> - pentru o componentă care poate fi executată în
noduri;
• <<library>> - pentru o componentă care reprezintă biblioteci;
• <<file>> - pentru o componentă care reprezintă un fişier de date sau
fişier sursă;
• <<table>> - pentru o componentă care reprezintă o tabelă a unei baze de
date;
• <<document>> - pentru o componentă care reprezintă un fişier
document.
Interfeţe
Componentele au numai operaţii, care pot fi accesate numai prin
intermediul interfeţelor lor. Interfeţele unei entităţi (clase sau componente)
reprezintă un set de operaţii pe care entitatea le pune la dispoziţia celorlalte
entităţi şi care sunt ascunse prin încapsulare.

Reprezentare

O interfaţă realizată de o componentă se numeşte interfaţă de export, în

sensul că interfaţa furnizează serviciile componentei celorlalte componente.
O componentă poate furniza mai multe interfeţe de export.
O interfaţă folosită de o componentă se numeşte interfaţă de import, în
sensul că o componentă care accesează serviciile alteia trebuie să se
conformeze interfeţei acesteia.
Relaţiile de dependenţă dintre componente

Relaţia de dependenţă dintre componente este o relaţie de la o

componentă client la o componentă furnizor (server) şi semnifică faptul
că entităţile (clasele) incluse în componenta client pot moşteni, instanţia
sau utiliza clasele incluse în componenta furnizor (server).

Dependenţele dintre componente se reprezintă, ca şi în cazul claselor,

prin linii punctate între componenta utilizator (client) şi componenta
furnizor de servicii (server), cu o săgeată orientată spre componenta
furnizor.

Se folosesc trei tipuri speciale de dependenţe stereotipizate, şi anume:

a) dependenţe de utilizare (use dependencies);
b) dependenţe de apartenenţă (reside dependencies);
c) dependenţe de desfăşurare (deploy dependencies).
a) Dependenţe de utilizare (use dependencies)

O dependenţă de utilizare este o relaţie de la componenta utilizator (client)

la componenta furnizor (server), care indică faptul că componenta client
foloseşte sau depinde de componenta furnizor.

O dependenţă de utilizare este reprezentată în mod asemănător cu relaţia

de dependenţă dintre clase, printr-o linie punctată, cu o săgeată spre
componenta furnizor sau spre interfaţa acesteia.
b) Dependenţe de apartenenţă (reside dependencies)

O dependenţă de apartenenţă este o relaţie de la o componentă client la un

element UML furnizor şi indică faptul că elementul furnizor aparţine
componentei (asemănător relaţiei de agregare dintre clase). Elementul
furnizor poate fi o clasă concretă sau o clasă stereotip (<<type>>,
<<implementation class>>, <<interface>>), pachete sau subsisteme.

Exemplu
componente:
- Interfaţa Utilizator, care furnizează o interfaţă prin care utilizatorul poate
interacţiona cu sistemul;
- Date – pentru implementarea funcţionalităţii datelor memorate;

pachete şi subsisteme:
- Interfaţa Utilizator, care grupează clasele care furnizează interfaţa cu
utilizatorul;
- Utilităţi – conţine date, timpul şi alte clase de utilităţi;
- Date - subsistem pentru prelucrarea datelor.

interfeţe:
IProduse – produse realizate (create sau scrise);
IConsumabile – produse folosite (citite sau distruse).
- pachetul Utilităţi aparţine ambelor componente;
- componenta Date conţine şi subsistemul Date, care este reprezentat
în interiorul componentei (modul doi de reprezentare), în timp ce
pachetul Utilităţi este legat printr-o relaţie de dependenţă de
componenta client Date (modul întâi de reprezentare);
- deoarece între pachetele Utilităţi şi Interfaţă Utilizator există o relaţie
de dependenţă, ele trebuie să facă parte din aceeaşi componentă, altfel
pachetul Interfaţă Utilizator nu va putea fi utilizat.
 Diagrame de desfăşurare
Diagrama de desfăşurare descrie structura sistemului în momentul
execuţiei. Ea prezintă dispunerea fizică a diferitelor elemente hardware,
numite noduri, care intră în componenţa unui sistem, şi repartizarea
programelor executabile pe aceste elemente. În diagrama de desfăşurare,
se indică nodurile şi conexiunile unui model.

Noduri
Un nod este resursa care este disponibilă în timpul execuţiei unui sistem
software şi reprezintă un procesor sau un dispozitiv, pe care vor fi
desfăşurate şi executate componentele sistemului.
Un procesor este un nod care poate executa o componentă (calculatoare în
reţea). Fiecare nod trebuie să aibă un nume. La nivelul fiecărui procesor pot
fi identificate procese. Un procesor trebuie să aibă memorie şi anumite
capabilităţi de procesare (dispozitive de calcul, resurse umane, etc.)

Un dispozitiv (echipament periferic) reprezintă un element hardware care, în

sistemul din care face parte, nu are putere de calcul. Fiecare dispozitiv
trebuie să aibă un nume, care poate fi generic, ca de exemplu: monitor,
imprimantă, tastatură, modem, etc.
Distincţia dintre un dispozitiv şi un procesor depinde de punctul de vedere
asupra acestora. De exemplu: un terminal T va fi privit ca un dispozitiv de
către utilizatorul terminalului şi ca un procesor pentru un produs software
care se execută pe procesorul terminalului T.

În UML, un nod se reprezintă printr-un paralelipiped (de multe ori este un

cub), care este etichetat cu numele nodului, ca în figura de mai jos:

Observaţii privind numele unui nod:

- în cazul în care nodul este o clasă, numele poate fi stereotipizat;
- în cazul în care nodul face parte dintr-un pachet, numele este prefixat
de numele pachetului şi separat de acesta prin simbolul “::”;
- în cazul în care nodul este un nod exemplu, numele său este urmat de
simbolul “:” şi de numele clasei de noduri, având toate părţile numelui
subliniate; ambele nume sunt opţionale, iar simbolul “:” este prezent
numai dacă este specificat numele clasei de noduri;
 Exemple

Clase de noduri:
- Client – tip procesor, pe care se execută componenta Interfaţă Utilizator;
- ServerBaze – tip procesor, pe care se execută componenta Date;
- Imprimantă – tip dispozitiv, folosită de sistem pentru a lista rapoarte;
Instanţe de clase de noduri:
- Andrei: Client; Ana: Client;
- O instanţă a nodului Server;
- Hp100: Imprimantă.
 Organizarea nodurilor şi legăturile dintre ele
Nodurile pot fi organizate în pachete, în acelaşi mod ca şi clasele şi
componentele.

O conexiune reprezintă un tip hardware care realizează cuplarea între două

noduri. Conexiunea poate fi directă, ca de exemplu prin cablu, reţea
Ethernet, linii telefonice, etc., sau indirectă, ca de exemplu conexiunea prin
satelit.
unde

T-connector
 Dependenţe de desfăşurare
O dependenţă de desfăşurare este o relaţie de la o componentă, numită şi
componentă client, la un nod, numit nod furnizor, şi indică faptul că nodul
conţine componenta respectivă.

O dependenţă de desfăşurare poate fi reprezentată în două moduri:

- printr-o relaţie de dependenţă (o linie punctată cu o săgeată) de la
componentă la nod şi având stereotipul <<desfăşurare>> sau <<deploy>>;
- componenta este reprezentată în interiorul nodului pe care este
desfăşurată (modul cel mai des utilizat).
 Exemplu de diagramă de componente şi de desfăşurare

Se consideră, iniţial, pachetele: Interfaţă Utilizator şi Utilităţi şi subsistemul

Raportare, care furnizează interfeţele: IVizualizare (pentru vizualizarea pe
ecran a rapoartelor) şi IPrintare (pentru printarea rapoartelor). Pe
parcurs se rafinează diagrama cu următoarele cerinţe:

1. Pachetul Interfaţă Utilizator foloseşte interfeţele IVizualizare şi IPrintare,

furnizate de subsistemul Raportare.
2. Pachetele Interfaţă Utilizator şi Utilităţi aparţin componentei
InterfaţăUtilizator.
3. Subsistemul Raportare şi pachetul Utilităţi aparţin de componenta
Raportare.
4. Componenta Interfaţă Utilizator este desfăşurată pe nodul Client.
5. Componenta Raportare este desfăşurată pe nodul Server Raport.
6. Nodul Client este conectat la nodul Server Raport, iar nodul Server
Raport este conectat la nodul Imprimantă .
Diagrame de interacţiune
 Introducere

Diagramele de interacţiune permit specificarea în detaliu a modului în care

obiectele interacţionează pentru a executa un task.

UML furnizează 2 tipuri de diagrame de interacţiune:

- diagrame de colaborare
- diagrame de secvenţă.

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.
 Diagrame de colaborare
Obiectele care interacţionează pentru a executa un task împreună cu
legăturile dintre ele formează o colaborare.

Interacţiunea este reprezentată de secvenţă de mesaje care sunt

transmise între obiecte.
Diagrama de colaborare cuprinde următoarele elemente:
a) Obiecte: dreptunghi în care sunt scrise numele obiectului şi numele
clasei, separate prin “:”, toate subliniate. Dacă numele obiectului nu are o
anumită semnificaţie, poate fi omis (:NumeClasa); nu este indicată
această utilizare dacă există două obiecte din aceeaşi clasă.

b) Legături: se reprezintă la fel ca asocierile

c) Actori: se reprezintă la fel ca în diagramele use-case. În cazul în care

colaborarea descrie un caz de utilizare, actorii din colaborare vor
corespunde cu actorii din diagrama use-case corespunzătoare. Pot exista
mai mulţi actori, însă numai unul singur va iniţia cazul de utilizare.
d) Mesaje: pe o diagramă de colaborare, numele mesajelor se reprezintă
alături de liniile ce descriu legaturile dintre obiecte, iar direcţia de
transmitere a mesajului e indicată printr-o săgeată.
Dacă un mesaj este transmis de la un obiect a:A către obiectul b:B, obiectul
destinatar (b) trebuie să înţeleagă mesajul, adică este necesar ca în clasa
din care face parte obiectul (B) să existe o operaţie corespunzătoare
mesajului. Cu alte cuvinte, construirea unor diagrame de interacţiune
contribuie la identificarea asocierilor dintre clase şi a operaţiilor claselor. E
posibil ca prima soluţie să nu fie cea optimă.
Cum circulă mesajele? (în varianta procedurală)
Un obiect începe să lucreze atunci când primeşte un mesaj; se spune că în
acel moment obiectul este activat. În cele din urmă, el trebuie să trimită un
răspuns 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.
Dacă trimite un mesaj, el va fi în continuare activ, dar nu va putea să lucreze
până când nu va primi răspuns la acest mesaj. Cu alte cuvinte, mesajul este
sincron, adică la transmiterea unui mesaj se transmite controlul celui care
primeşte mesajul. În fiecare moment, 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 răspuns încă. Obiectul asociat cu activarea aflată în vârful stivei
are controlul şi poate să lucreze; obiectele asociate cu celelalte activări
aşteaptă răspuns la mesajele pe care le-au trimis.
Dacă obiectul asociat activării din vârful stivei trimite un mesaj, obiectul
care primeşte mesajul primeşte şi controlul, iar activarea sa va fi
poziţionată în vârful stivei.
Pe de altă parte, obiectul asociat activării din vârful stivei poate să-şi
termine lucrul şi să răspundă la mesajul care l-a activat, fiind astfel înlăturat
din stivă. În acest caz, următoarea activare va deveni vârful stivei, iar
obiectul asociat acesteia va recăpăta controlul.
Obs. Nu este necesară reprezentarea mesajelor de răspuns într-o diagramă
de colaborare.

Pentru a ţine evidenţa numărului de stive de activare, mesajele sunt

numerotate, folosind următoarea regulă: primul mesaj transmis de la un
obiect la altul este numerotat cu 1 (nu este socotit primul mesaj de la
actorul care iniţiază interacţiunea la un obiect). Când un obiect a primeşte
un mesaj, numărul acelui mesaj va fi folosit ca prefix pentru toate mesajele
trimise până când a răspunde la acest mesaj.
Exemplu: dacă mesajul care îl activează pe a este numerotat cu 2.1, atunci
toate mesajele trimise între acest moment şi răspunsul la acest mesaj vor fi
numerotate cu 2.1.n.
Fig. Exemplu de numerotare a mesajelor
 Diagrame de secvenţă
O astfel de diagramă pune în evidenţă transmiterea mesajelor de-a lungul
timpului.

Obiectele şi actorii sunt reprezentaţi la capătul de sus al unor linii punctate,

care reprezintă linia de viaţă a obiectelor, adică timpul aşa cum este
perceput el de obiecte.
Timpul cât este activat un obiect este reprezentat ca un dreptunghi subţire
ce acoperă linia de viaţă.
Opţional, părţi din acest dreptunghi pot fi haşurate, pentru a indica perioada
de timp cât acesta lucrează. Tot opţional pot fi reprezentate şi răspunsurile
la mesaje, printr-o linie punctată.
 Facilităţi suplimentare ale diagramelor de interacţiune
Mesaje de la un obiect către el însuşi
Într-o diagramă de colaborare, se reprezintă printr-o legătură între obiectul
respectiv şi el însuşi. Într-o diagramă de secvenţă, se reprezintă printr-o
săgeată de la linia de viaţă a obiectului către ea însăşi. În acest caz,
dreptunghiul subţire reprezentând noua activare este puţin deplasat faţă de
cel reprezentând vechea activare.
Reprezentarea valorilor returnate de mesaje
În UML o valoare returnată este reprezentată pe săgeata reprezentând
mesajul iniţial ca o atribuire către o variabilă având un nume nou (vezi
figura de pe pagina următoare).

Crearea şi distrugerea obiectelor

a) Diagramele de colaborare arată care obiecte sunt create şi distruse în
timpul interacţiunii folosind stereotipurile «create» şi «destroy» înaintea
mesajelor corespunzătoare. Alternativ, faptul că un obiect a fost creat sau
distrus în cadrul interacţiunii se poate reprezenta prin constrângerile {new},
respectiv {destroyed} plasate în dreptunghiul care reprezintă obiectul (vezi
figura de pe pagina următoare). Dacă un obiect este atât creat cât şi distrus
în timpul interacţiunii, se poate folosi constrângerea {transient}.

b) Diagramele de secvenţă arată că un obiect este creat prin plasarea

acestuia în josul paginii. Distrugerea unui obiect este reprezentată printr-un
X la sfârşitul dreptunghiului reprezentând perioada de activare. Dacă un
obiect e distrus de alt obiect va exista un mesaj de la obiectul care
efectuează operaţia de distrugere către semnul X.
Reprezentarea constrângerilor de timp
La diagramele de secvenţă, e util de ştiut şi momentele efective la care apar
mesajele. Modalitatea eficientă furnizată de UML este scrierea unor
constrângeri de timp.
Reprezentarea la diferite nivele de abstracţie
Pentru ca interacţiunea să fie descrisă la un nivel mai înalt de abstracţie, se
poate folosi o subcolaborare, adică o submulţime de obiecte împreună cu
legăturile dintre ele. O subcolaborare poate fi privită ca un singur element şi
poate fi reprezentată ca un pachet.
Exprimarea condiţiilor

În UML transmiterea unui mesaj poate depinde de îndeplinirea unei condiţii.

În cadrul diagramei, condiţiile vor apărea în paranteze drepte şi vor fi
poziţionate în faţa mesajelor corespunzătoare.

Dintr-un punct pot pleca orice număr de mesaje, cu condiţia ca acestea să

aibă condiţii disjuncte. O diagramă de secvenţă cu mesaje alternative
însoţite de condiţii poate fi implementată folosind structuri “if-else” sau
“case”.

În cazul în care mai multe mesaje alternative sunt trimise aceluiaşi obiect,
pentru a scoate în evidenţă că una dintre alternativele respective nu poate fi
aleasă decât una şi ele nu pot exista simultan, în diagramele de secvenţă
linia de viaţă a obiectului destinatar va avea mai multe ramificaţii, fiecare
corespunzând unei alternative.
Exemplu. Să presupunem exemplu cu centrul de închirieri CD-uri şi casete,
adăugăm ipoteza că există 2 tipuri de CD-uri: obişnuite şi speciale. CD-urile
obişnuite pot fi împrumutate pentru o perioadă mai lungă (3 săptămâni), în
timp ce CD-urile speciale mai puţin (1 săptămână).
Iteraţii
Pentru a arăta că un mesaj poate fi trimis în mod repetat se foloseşte un
asterisc poziţionat după numărul mesajului. În plus, după asterisc se poate
indica o clauză de iteraţie (plasată între paranteze drepte), care determină
de câte ori va fi trimis mesajul.

Exemple:
• [n<10]: este echivalentul condiţiei while;
• [not x];
• [i:=1..10]: este echivalentul condiţiei for;
• [y in Y]: mesajul e trimis în mod repetat pentru fiecare y din colecţia Y
Figura de mai jos reprezintă diagrama de secvenţă pentru cazul unui client
care cumpără un număr de produse dintr-un magazin.
Dacă un mesaj care e transmis în mod repetat are ca rezultat transmiterea
unui alt mesaj, atunci transmiterea acestuia din urmă va fi repetată ori de
câte ori e transmis şi primul mesaj, dar acest lucru nu va fi arătat pe
diagramă.

Exemplul1. Ce rezultat va avea figura de mai jos?

Răspuns: xyxy.
Exemplul1. Ce rezultat va avea figura de mai jos?

Răspuns: xyyxyy.
 Concurenţa

Până acum s-a considerat tipuri de interacţiune procedurală, în care, după

transmiterea unui mesaj, obiectul care trimite mesajul aşteaptă răspunsul
înainte de a-şi continua funcţionarea. Este cazul cel mai întâlnit în practică,
deoarece majoritatea sistemelor funcţionează pe un singur procesor.

În cadrul sistemelor concurente, există cazurile:

• un obiect trimite simultan mai multe mesaje: se reprezintă prin mai multe
săgeţi care pleacă din acelaşi loc, fără a avea asociate condiţii
• un actor sau un obiect activ trimite un mesaj la un anumit moment, deşi
obiectul care lucrează în acel moment este alt obiect din sistem
• un obiect trimite un mesaj asincron, adică un mesaj care poate face ca alt
obiect să lucreze fără ca obiectul care atrimis mesajul să-şi înceteze lucrul.

În primul caz, schema de numerotare îmbricată descrisă mai devreme va fi

extinsă, în sensul posibilităţii ca la numerotarea mesajelor să apară nume
sau litere care să diferenţieze mesajele trimise simultan. În ultimele 2
situaţii, schema de numerotare îmbricată îşi pierde sensul, putându-se
folosi numerotarea secevnţială.
 Tipuri de mesaje

Există mai multe tipuri de mesaje în UML:

• mesaje sincrone : specifice funcţionării procedurale

• mesaje de răspuns : reprezentarea e opţională

• mesaje asincrone : nu aşteaptă răspuns, obiectul rămâne activ

• mesaje simple : nu aşteaptă răspuns, obiectul pierde controlul

Exemplul1. La centrul de închirieri se consideră că există şi o componentă
de statistică, responsabilă cu evidenţa CD-urilor care devin indisponibile la
un moment dat (toate copiile au fost împrumutate).

Figura arată folosirea unui mesaj asincron.

Exemplul2 (pentru folosirea mesajelor simple). Automat pentru băuturi:
cerinţe

• casa de bani va verifica dacă suma de bani introdusă de client corespunde

cu preţul băuturii selectate;
• dacă suma este egală cu preţul, containerul de băuturi va livra produsul;
• dacă suma este mai mare decât preţul, casa de bani va calcula restul şi va
verifica dacă acesta e disponibil în casă;
• în cazul în care restul e disponibil, casa de bani returnează acest rest, iar
magazia oferă produsul selectat;
• dacă restul nu e disponibil, casa de bani va returna banii clientului;
• dacă suma introdusă de client e mai mică decât preţul produsului, casa de
bani va aştepta mai mulţi bani şi nu va face nimic.