Ministerul Educației Republicii Moldova

Universitatea Tehnică a Republicii Moldova

Facultatea Calculatoare,Informatică și Microelectronică
Departamentul Ingineria Software și Automatică

PROIECT DE AN
La disciplina: Instrumente de dezvoltare în Web (IDWeb)

Tema:
ANALIZA ȘI MODELAREA UNEI APLICAȚII BANCARE

A realizat: st.gr. TI-191 F/R, Onisim

Ariadna

Au verificat : Lector univ. Poddukin Vladimir,

 Chișinău, 2022
CUPRINS

INTRODUCERE............................................................................................................................ 3

1. ANALIZA ȘI MODELAREA ORIENTATĂ PE OBIECT..................................................... 4

1.1. Analiza și conceperea sistemelor orientate pe obiect........................................................ 5
1.2. Limbajul UML.................................................................................................................. 7
1.3. Structura generală a limbajului UML................................................................................ 9
2. DESCRIEREA SISTEMULUI și REPREZENTAREA ÎN LIMBAJUL UML .................... 11
2.1. Descrierea sistemului modelat......................................................................................... 11
2.2. Reprezentarea diagramelor UML.................................................................................... 12
2.2.1. Diagrama caz de utilizare ..................................................................................... 12
2.2.2. Diagrama de secvență............................................................................................ 16
2.2.3. Diagrama de colaborare........................................................................................ 22
2.2.4. Diagrama claselor.................................................................................................. 26
2.2.5. Diagrama stărilor................................................................................................... 33
2.2.6. Diagrama activităților............................................................................................ 36
2.2.7. Diagrama componentelor...................................................................................... 38
2.2.8. Diagrama de plasare.............................................................................................. 43

CONCLUZII................................................................................................................................. 44

REFERINȚE BIBLIOGRAFICE................................................................................................. 45

ANEXE......................................................................................................................................... 46

Anexa 1. Lista de figure și tabele........................................................................................... 46

Anexa 2. Glosar termeni......................................................................................................... 47

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 2 | Page
 INTRODUCERE

Această lucrare va explora principiile care stau la baza Analizei și Modelării Orientate pe
Obiecte, se vor analiza și implementa cunoștințele despre diagramele UML - reprezentări din
diferite perspective ale proceselor care apar în aplicație, care ne permit să înțelegem mai bine
funcționarea programului, modul în care acesta este realizat și, în cazul originea problemei este
sursa ei. Înainte de a proiecta un sistem de orice scară, orice inginer trebuie să efectueze un
studiu al problemei, apoi să transfere problema practică la un model matematic și apoi să
construiască un model al sistemului real folosind acest model.

În această lucrare, cea mai mare prioritate nu este o descriere detaliată a întregului sistem,
ci studiul metodelor de analiză și proiectare a sistemelor. Pentru cele mai vizuale și modele
simplificate și modele, există un limbaj unificat de modelare UML. Numărul relativ mare de
tipuri de diagrame UML ne oferă diferite posibilități de reprezentare a sistemului selectat, creând
spațiu liber și liber pentru crearea unei diagrame. Unul dintre instrumentele care acceptă
specificația limbajului UML este software-ul de modelare Enterprise Architect. Acest instrument
va fi folosit, în comparație cu alte instrumente care suportă specificațiile limbii UML, Enterprise
Architect are o interfață mai intuitivă și mai convenabilă. Prin urmare vom caracteriza, analiza și
modela sistemul informational – Aplicație bancară.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 3 | Page
 1. ANALIZA ȘI MODELAREA ORIENTATĂ PE OBIECT

Analiza și modelarea sistemelor informaționale comport o varietate mare de activități și

manipularea unor mari volume de informații. Scopul final este realizarea sistemului
informational bazat pe un sistem de prelucrare automata a datelor, integrat.

Sistemul informational trebuie să se realizeze pe baza unei analize amănunțite a sistemului

condus și a sistemului de conducere. Sistemul informational cuprinde ansamblul informațiilor
interne și externe utilizate în cadrul lui precum și datele care au stat la baza obținerii lor,
procedurile și tehnicile de obținere a informațiilor(plecînd de la datele primare) și de difuzare a
informațiilor, precum și personalul implicat în culegerea, transmiterea, stocarea și prelucrarea
datelor.

Modelarea este parte esențială în orice proiect software, în special în proiectele mari.

Modelele sunt:
a. Reprezentări abstracte ale sistemului
b. Create în etapele care preced codificarea:
- Analiza și specificarea cerințelor
- Proiectarea arhitecturală
- Proiectarea de detaliu
c. Utilizate înainte de codificare pentru a verifica dacă toate cerințele utilizatorilor sunt
acoperite, dacă funcțiile prevăzute sunt complete și correct modelate, dacă arhitectura
este robustă și extensibilă și după codificare pentru verificarea și validarea sistemului

Modelele de definiție și analiză a cerințelor:

a. Exprimă cerințele impuse sistemului
b. Corespund unei vederi externe asupra sistemului
c. Se folosesc de către slient, viitorii utilizatori ai sistemului, experți ai domeniului
aplicației, analiști, echipa de verificare și validare a sistemului.

Modelele de proiectare:
a. Redau arhitectura sistemului, alocarea cerințelor pe subsisteme, distribuția proceselor în
sistem, sincronizarea lor

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 4 | Page
 b. Realizarea fizică a sistemului, echipamentele din componența sa și repartiția
componentelor program pe diferite componente hardware.

În etapa de proiectare se construiesc modele care redau arhitectura sistemului, alocarea

cerințelor pe subsisteme, distribuția proceselor în sistem, sincronizarea lor, sterile și tranzițiile
între stări. Alte modele descriu realizarea fizică a sistemului, echipamentele din componența sa și
repartiția componentelor program.

Principalele scopuri ale modelării sistemelor informaționale sunt:

a. Vizualizarea, ca mijloc de ușurare a comunicării și înțelegerii
b. Specificarea, prin construirea de modele precise, neambigue și complete
c. Documentarea cerințelor, a soluțiilor de proiectare și a modului de realizare

În faza de proiectare logică se efectuează deplasarea atenției de la prezentarea a cee ace există ș
ice se intenționează la descrierea a ceea ce va însemna noul sistem și cum va funcționa.
Prezentarea noului sistem constă în prezentarea tuturor intrărilor sistemului, a ieșirilor, precum și
a interfețelor și dialogurilor.

Proiectarea fizică este cunoscută și sub numele de proiectare de detaliu. În timpul proiectării
logice se prezintă o imagine general a sistemului, în timp ce proiectarea fizică înseamnă o
abordare detaliată a sistemului. Cu alte cuvinte, în etapa de proiectare logiă se acumulează
informațiile de natură să sintetizeze cerințele utilizatorilor noului sistem, operațiune prestată de
analiștii de sistem, iar în timpul proiectării fizice se prezintă punctele de vedere ale specialiștilor,
cum ar fi cei din domeniul programării, securității sistemelor, rețelelor, etc.

1.1 Analiza și conceperea sistemelor orientate pe obiect

Programarea orientate pe obiect este unul din ei mai importanți pași făcuți în evuluția
limbajelor de programare spre o mai puternică abstractizare în implementarea programelor. Ea a
apărut din necesitatea exprimării problemei într-un mod mai natural ființei umane. Astfel
unitățile care alcătuiesc un program se apropie mai mult de modul nostru de a gîndi decît modul
de lucru al calculatorului. Pînă la apariția programării orientate pe obiect, programele erau
implementate în limbaje de programare procedural(C, Pascal) sau în limbaje care nici măcar nu
oferea o madalitate de gruparea instrucțiunilor în unități logice, precum funcții sau proceduri
cum este cazul limbajului de asamblare Assembly.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 5 | Page
 Tehnicile orientate obiect constituie un nou mod de abordare a produselor informatice,
bazat pe abstractii ce corespund lumii reale. Obiectele din domeniul aplicatiei formeaza cadrul de
lucru pentru definirea unui model si ulterior conduc la implementare.

In timp ce in faza de definire a modelelor sistemului real obiectele cu caracteristici

comune sunt grupate in clase, in faza de implementare obiectele sunt definite ca instante ale
claselor, partajand proprietati si metode.

Pana in faza finala dezvoltarea orientata obiect este un proces conceptual independent de
limbajul de programare. Poate servi ca mediu pentru analiza si documentare, pentru definirea
interfetei cu utilizatorul, sau pentru programare. Greutatea consta in identificarea si organizarea
conceptelor din domeniul aplicatie. Reprezentarea finala intr-un limbaj de programare, (orientat
obiect sau nu) si stabilirea detaliilor de structurare a datelor ocupa un loc secundar.

Problema de bază într-un limbaj orientat obiet este identificarea entităților. Odată
identificate entitățile ele nu rămîn isolate, ele vor fi grupate în module, pachete, programe, etc.,
care vor stabili legături între ele. Aceste legături reflect relațiile care se stabilesc între
clasele/obiectele problemei pe care am preluat-o din natură. Extinzînd exemplul de mai sus, vom
adăuga o nouă clasă: „Raft”, care va avea următoarele proprietăți: „număr” și „conținut”. Vom
instanția clasa „raft” atribuind valori atributelor respective „1” și „fructe”. Bineînțeles că acest
raft va fi în relație cu clasa „fruct” pe care am exemplificat-o mai devreme. Astfel, el conține
obiecte de tip „fruct”.

Metodele orientate obiect acopera intregul ciclul de viata impartit in trei etape: analiza,
proiectare, implementare. In aceste etape se intalnesc, in planuri conceptuale diferite, elemente
orientate obiect, notatii din domeniul aplicatiei si al computerelor. In faza de analiza se
construieste un model pentru abstractizarea aspectelor esentiale din domeniul aplicatiei. Modelul
nu cuprinde detalii de implementare. Pentru a descrie si optimiza implementarea, acestea sunt
adaugate in etapa de proiectare.

ANALIZA

In faza de analiza se construieste un model precis, concis si inteligibil al lumii reale, un

model complet al aplicatiei. Analistul descrie ce trebuie sa faca sistemul si nu cum o face,
urmareste definirea a ceea ce urmeaza sa realizeze, si nu a algoritmilor care vor fi folositi.
Obiectele sunt concepte din domeniul aplicatiei, si nu din domeniul programarii. Atentia este
indreptata asupra conceptelor care vor forma nucleul unei solutii ce utilizeaza tehnici orientate
obiect.
_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 6 | Page
 Analiza este selectiva, neacordandu-se aceeasi importanta tuturor componentelor si
insusirilor. Lumea reala se descompune in entitati distincte, se stabilesc legaturile dintre ele si
functiile indeplinite. Sunt examinate cerintele, analizate implicatiile, retinute doar aspectele
esentiale. Rezultatul este un model cu clase si asocieri, folosirea acestora facandu-se in partea de
proiectare si implementare. Putem distinge : Analiza cerintelor, faza ȋn care se face o analiza
preliminara a comportamentului extern al sistemului si se include in contextual concret ȋn care va
functiona; este ca un contract intre dezvoltatori si beneficiari. Exprima ce poate face sistemul, in
termeni din domeniul aplicatiei. Cerintele sunt clasificate in cerinte functionale, care evidentiaza
ce face sistemul si cerinte nefunctionale, ce vieaza performantele sistemului ( fiabilitate, calitate
a interfetei, etc)

PROIECTAREA

Proiectarea se ocupa de cum va opera sistemul si-l descompune in componente ce pot fi

dezvoltate individual, oferind totodata o vedere de ansamblu asupra sistemului.

Scopul principal al proiectarii orientate obiect este sa maximizeze posibilitatea reutilizarii

claselor in proiecte ulterioare, sa identifice in relatiile de mostenire superclasele care faciliteaza
reutilizarea in cadrul aceluiasi proiect.

Proiectarea se efectueaza in doua etape: proiectarea sistemului si proiectarea obiectelor.

Proiectarea sistemului implica impartirea sa in subsisteme, si alocarea resurselor hardware si
software. Proiectarea obiectelor continua strategia aleasa in etapa de proiectare a sistemului si
rafineaza detaliile. Se pastreaza structura claselor stabilita in partea de analiza, luand in
considerare minimizarea timpului de executie si folosirea rationala a memoriei. Operatiile
identificate in etapa de analiza sunt exprimate algoritmic, cele complexe sunt descompuse in
operatii interne simple. Atributele si asocierile sunt prezentate intr-o forma ce permite ulterior
implementare ca structuri de date specific. Clasele sunt rearanjate prin evidentierea unor relatii
de agregare sau de generalizare, sunt completate cu noi operatii si noi atribute, rezultate din
abstractizarea comportamentului comun. Modelul claselor poate fi rafinat prin introducerea de
noi clase, care pastreaza rezultate intermediare de calcul.

1.2 Limbajul UML

Unified Modeling Language (prescurtat UML) este un limbaj standard pentru descrierea
de modele și specificații pentru software. Limbajul a fost creat de către consorțiul Object

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 7 | Page
Management Group (OMG) care a mai produs printer altele și limbajul de programare CORBA.
UML a fost la bază dezvoltat pentru reprezentarea complexității programelor orientate pe obiect,
al căror fundament este structurarea programelor pec lase, și instanțele acestora (numite și
obiecte). Cu toate acestea, datorită eficienței și clarității în reprezentarea unor elemente abstracte,
UML este utilizat dincolo de domeniul IT. Așa se face că există aplicații ale UML-ului pentru
management de proiecte, pentru Business Process Design etc.

Istoria dezvoltării limbajului UML începe în luna octombrie a anului 1994, cînd Grady Booch și
James Rumbaugh din Rational Software Corporation au început să lucreze împreună asupra
unificării metodelor Booch și OMT. Cu toate că aceste metode fiecare în parte erau destul de
cunoscute, lucrul în comun era organizat pentru cercetarea tuturor metodelor OO cu scopul
unificării celor mai avantajoase trăsături ale lor. Proiectul acestei așa zise metode unificare
(Unified Method) versiunea 0.8 a fost pregătit și publicat în luna octombrie anului 1995. În
toamna aeluiași an a aderat la ei și Iv. Jacobson, tehnologul principal al companiei Objetory AV
(Suedia), cu scopul integrării metodei sale OOSE cu celelalte două precedente.

Componente de bază ale limbajului UML

Limbajul UML reprezintă limbajul de destinație general ale modelării vizuale, care este elaborate
pentru specificarea, vizualizarea, construirea și documentarea componentelor produsului soft,
business-proceselor și altor sisteme. Totodată limbajul UML este un mijloc de modelare simplu
și puternic care poate fi utilizat efetiv pentru construirea modelelor conceptuale, logice și grafice
ale sistemelor complexe de diferită destinație, Acest limbaj conține cele mai bune calități ale
metodelor ingineriei de program care au fost utilizate cu success pe parcursul utlimilor ani la
modelarea sistemelo complexe.

Limbajul UML este bazat pe un anumit număr de noțiuni principale care pot fi studiate și
applicate de către majoritatea programitilor și elaboratorilor cunoscuți cu metodele de analiza și
proiectarea obiect orientate. Totodată noțiunile de bază pot fi combinate și extinse în ala fel că
specialițtii modelării orientate pe obiecte pot elabora de sinestătător modele ale sistemelor
complexe în diferite domenii de aplicare.Utilizarea constructive a limbaului UML este bazată pe
ințelegerea principiilar commune de modelare a sistemelor complexe și a particularităților
procesului de analiza și proiectarea obiect orientate.

Alegerea mijloacelor expressive pentru construcția modelelor ale sistemelor complexe stabilește
din vreme problemele care pot fi rezolvate cu ajutorul utilizării acestor modele. Totodată unul
din principiile de bază pentru construirea modelelor ale sistemelor complexe este principiul de

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 8 | Page
abstractizare care presupune includerea în model numai a aelor aspect ale sistemului proietat,
care au nemijloit legătura cu executarea de către sistem a funcțiilor sale sau cu destinația lui de
bază.

Totodată toate detaliile de importanță secundară sunt omise pentru ca procesul de analiză și
cercetare a modelului primit să nu fie foarte complicat. 

UML nu este o metoda, este o notatie grafica care acopera majoritatea tipurilor de
diagrame necesare in timpul ciclului de viata al dezvoltarii software.

PUNCTELE FORTE:
a. este un cadru de analiza obiect, oferind:
- diferite perspective complementare ale sistemului, care ghideaza utilizarea
conceptelor obiect
- numeroase nivele de abstractizare, care permit controlul complexitatii cu ajutorul
solutiilor obiect
b. este un suport de comunicatie
- notatia grafica permite exprimarea vizuala a unei solutii obiect
- aspectul formal al notatiei sale limiteaza ambiguitatile
- aspectul vizual faciliteaza evaluarea si compararea solutiilor
c. este un limbaj formal si normalizat care:
- castiga precizie
- castiga stabilitate
- incurajeaza utilizarea instrumentelor CASE
d. asigura independenta fata de limbajul de implementare si de domeniul aplicatiei

PUNCTE SLABE:
a. ▪ punerea in practica a limbajului UML necesita pregatire complexa de specialitate
b. ▪ permite reprezentarea modelelor, dar nu defineste procesul de elaborare al modelelor.
Este un demers iterativ si incremental, ghidat de cerintele/nevoile utilizatorilor de sistem
c. ▪ nu descrie cum se dezvolta software-ul, dar se poate folosi cu orice proces.

1.3 Structura generală a limbajului UML

UML constă din două părți interdependente:

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 9 | Page
 1. Semantica limbajului UML reprezintă un careva metamodel, care definește sintaxa
abstractă și semantica noțiunilor modelării orientate pe obiecte în limbajul UML.
2. Notația limbajului UML reprezintă o notație grafică pentru reprezentarea vizuală a
semanticii limbajului UML.

Sintaxa abstractă şi semantica limbajului UML sunt descrise cu ajutorul unei anumite
submulţimi de notaţii ale UML.

În completare la aceasta, notatia UML descrie corespunderea sau reprezentarea notaţiei

grafice în semantica noţiunilor de baza. În aşa fel din punct de vedere funcţional aceste două
părţi completează una pe altă. Totodată semantica limbajului UML este descrisă pe baza unui
metamodel care are trei reprezentări aparte: sintaxa abstractă, reguli de construcţia corectă a
expresiilor şi semantica. Cercetarea semanticii limbajului UML presupune un careva stil
semiformal de redare, care unifica limbaje naturale şi formale pentru reprezentarea noţiunilor de
baza şi regulilor de extindere a lor.

Semantica se defineşte pentru două tipuri de modele de obiecte: de structura şi de comportare.

Modelele de structură, cunoscute ca modele statice, descriu structura entităţilor sau a
componentelor unui sistem inclusiv clase, interfeţe, atribute şi relaţii. Modelele de comportare,
numite uneori dinamice, descriu comportarea sau funcţionarea obiectelor unui sistem, inclusiv
metodele lor, colaborarea între ele, şi procesul de schimbare a stărilor unor componente aparte şi
al sistemului întreg.

Dicționarul limbajului include trei tipuri de construcții de bază:

a. Entități – abstarcții ce sunt elementele de bază a modelului

b. Relații – legături între entități
c. Diagrame ce grupează interesele entităților și relațiilor

Diagrame UML

În cadrul limbajului UML toate reprezentările modelului unui sistem complex sunt fixate în
calitate de construcții special grafice care deseori sunt reprezentate sub formă de graf conex cu
noduri – entități și muchii – relații. În UML sunt definite nouă tipuri de diagrame:

1. Diagrame de clase (class diagram)

2. Diagrame de comportament (behavior diagrams)
a. Diagrame de stări (statechart diagram)
b. Diagrame de activități (activity diagram)

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 10 | Page
 3. Diagrame de interacțiune (interation diagrams)
4. Diagrame de secvență (sequence diagram)
5. Diagrame de colaborare (collaboration diagram)
6. Diagrame de realizare (implementation diagrams)
7. Diagrame de componente (component diagram)

2. DESCRIEREA SISTEMULUI și REPREZENTAREA ÎN LIMBAJUL UML

2.1. Descrierea sistemului modelat

Aplicație bancară

Serviciul bancar online a devenit destul de popular datorită ușurinței de utilizare de

același lucru prin aplicații bancare și, de asemenea, cu aplicațiile lor oficiale. Funcționarea online
vă permite să vedeți toate mișcările în doar un minut, deoarece este timpul necesar pentru a
accesa.

Lucrul bun al fiecărei bănci este să ai o aplicație confortabilă, cu o interfață simplă și, în același
timp, cât mai rapid posibil pentru a consulta orice informație. Există multe opinii pozitive și
negative despre aplicațiile bancare.

Banca online îți trimite cardul, ai un număr de cont și este tocmai unul dintre cele care are
cele mai puține comisioane, se întâmplă cu alte bănci online ale concurenței. Aplicația bancară
vă permite să plătiți cu telefonul mobil, să trimiteți bani cu sau transfer, efectuați sau primiți
transferuri și tot ce căutați de la o bancă. Aplicația este destul de completă pentru a putea vedea
toate operațiunile, plăti, primi și totul prin intermediul aplicației sau, de asemenea, prin
intermediul site-ului web. Una dintre băncile cu cele mai multe sedii din lume nu ar putea lipsi
printre aplicațiile bancare, funcționează destul de bine și opiniile sunt cu adevărat pozitive.
Clienții cu un cont pot accesa prin intermediul aplicației și pot verifica totul despre starea băncii:
cele mai recente operațiuni, pot efectua transferuri, printre altele.

Puteți efectua transferuri naționale și internaționale către orice bancă, retrage bani de la un
bancomat fără card, puteți salva operațiunile preferate etc. Putem porni și dezactiva cardurile,
putem schimba limita la bancomate, transferați bani din contul dvs. către altul și alte servicii
multiple. Ne oferă opțiunea de a crea carduri virtuale pentru a le cumpăra de pe Internet Fără a
vă dezvălui detaliile cardului, solicitați un card și verificați asigurarea contractată.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 11 | Page
Notificările sunt gratuite, de aceea vă va notifica dintre toate acele mișcări pe care le efectuați,
ceva normal și mai mult dacă vă retrageți de la bancomat cu cardul sau cu carnetul. Vă permite
să căutați bancomate cu un motor de căutare integrat.

2.2. Reprezentarea diagramelor UML

2.3.

Figura 1. Model al unui sistem complex în notația UML

Fiecare din aceste diagrame detalizează şi concretizează diferite reprezentări despre modelul unui
sistem complex în termenii limbajului UML. Totodată diagrama cazurilor de utilizare reprezintă
cel mai general model conceptual al unui sistem complex care este iniţial pentru construirea
tuturor celorlalte diagrame. Diagrama de clase este un model logic care reflectă aspectele statice
ale procesului de construire structurală a unui sistem complex.

Diagramele de comportament la fel sunt varietăţi ale unui model logic care reflectă aspectele
dinamice ale procesului de funcţionare a unui sistem complex. Diagramele de realizare sunt
destinate reprezentării fizice a componentelor sistemului complex şi de aceea sunt atribuite
modelului fizic.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 12 | Page
 2.3.1. Diagrama caz de utilizare

Proiectarea unei diagrame a cazurilor de utlizare urmărește scopurile următoare:

- Determinarea limitelor commune și a contextului domeniului de modelare la etapele
inițiale de proiectare a unui sistem
- Formularea cerințelor commune către comportare funcțională a sistemului proiectat
- Elaborarea modelului initial conceptual al unui sistem pentru detalierea de mai tîrziu în
forma modelelor logice și fizice
- Pregătirea documentației inișiale pentru interacțiunea elaboratorilor unui sistem cu
clienții și utilizatorii

Esenţa acestei diagrame constă în faptul că: sistemul proiectat se reprezintă ca o colecţie de
entităţi şi actori care colaborează cu sistemul cu ajutorul aşa numitor cazuri de utilizare.

Cazul de utilizare deteremina o succesiune de actiuni care trebuie sa fie executate de catre
sistemul proiectat la colaborarea lui cu un anuimt actor.

Scopul cazului de utilizare constă în determinarea aspectului terminal sau fragmentului de

comportare a unei entităţi fără desfăşurarea structurii interne a acestei intităţi. În calitate de aşa
entitate poate fi un sistem iniţial sau un element al modelului care dispune de comportament
propriu, precum este subsitemul sau clasa în modelul unui sistem.

Actorul reprezintă orice entitate externă sistemului modelat, care colaborează cu sistemul şi
utilizează posibilităţile lui funcţionale pentru atingerea anumitor scopuri şi pentru rezolvarea
problemelor particulare.

Interfaţa (interface) specifică parametrii modelului care sunt vizibili din afară fără indicarea
structurii lor interne. În limbajul UML interfaţa este clasificatorul care caracterizeză numai o
parte limitată a comportării unei entităţi modelate.

Între interfață și caz de utilizare putem folosi 2 relații: asocierea și dependența

Relațiile diagramei caz de utilizare:

- Actor – Actor: dependență, generalizare
- Actor – Caz de utilizare: asociere
- Caz de utilizare – Caz de utilizare: dependența (stereotipuri: „include”, „extend”,
„depends”)
_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 13 | Page
 IMPLEMENTARE, REZULTATE PRACTICE:
Diagrame use-case pentru sistemul informațional ales.
Sistemul informațional – Aplicație bancară, prin intermediul căreia se pot efectua diverse
operații, tranzacții.

1. Diagrama use-case: Funcțiile aplicației bancare.

Funcțiile de bază ale acestui sistem sunt:
a. Verificarea contului bancar.
b. Alimentarea contului bancar
c. Achitare facturi.

Figura 2. Funcțiile aplicației bancare

2. Diagrama use-case - Verificare cont bancar:

Acest caz de utilizare își propune verificarea contului bancar ( a sumei de bani aflată în
contul unui anumit utilizator), iar pentru a fi afișată informația despre cont, este nevoie să se
parcurgă anumite etape, și anume: descărcarea aplicației la banca conevenită, crearea unui cont și
verificarea finanțelor.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 14 | Page
 Figura 3. Verificare cont bancar

3. Diagrama use-case - Achitare servicii

În figura 4 avem prezentată Diagrama use-case <<Achitare servicii>>, aceasta presupune

selectarea uneia din cele 3 servicii, și anume:

a. achitare comunale: achitare apă, achitare gaz, achitare căldura, achitare energie
electrică.

b. achitare internet: achitare orange, achitare starnet, achitare moltelecom.

c. achitare microfinanțare: microinvest, invest-credit, finexpres.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 15 | Page
 Figura 4. Achitare servicii

4. Diagrama use-case - Transfer bancar

În figura 5 avem prezentată Diagrama use-case - Transfer bancar, aceasta presupune

selectarea uneia din cele transferuri, și anume: transfer către mine și către altcineva.

Figura 5. Transfer bancar

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 16 | Page
 2.3.2. Diagrama de secvență

Descriere generală

Pentru modelarea dinamicii sistemului, UML furnizează două tipuri de diagrame, și

anume:

1. diagramele de interacțiune (diagrama de secvență și diagrama de

colaborare)

2. diagramele de comportament (diagrama de stare și diagrama de

comportament).

Principala menire a acestor diagrame este de a arăta cum realizează sistemul un caz de
utilizare sau un scenariu particular dintr-un caz de utilizare. Pentru fiecare caz de utilizare se pot
realiza maimulte scenarii (din descrierea cazului de utilizare). Pentru fiecare astfel de scenariu
se pot întocmi, nu este obligatoriu, o diagramă de secvență sau o diagramă de colaborare. Cum
decidem ce tip de diagramă să folosim? Dacă cel mai important aspect este timpul sau secvenţa
de mesaje vom folosi diagrama de secvenţă, dar dacă trebuie scos în evidentă contextul, vom
apela la odiagramă de colaborare.

Scenariile cazurilor de utilizare se dezvoltă în mod natural din diagrama de secvență.

Diagramele de secvențe transformă evenimentele identificate în scenariile cazurilor de
utilizareîntr-o reprezentare grafică a utilizărilor sistemelor de către actor. Diagrama de secvență
descriecronologic interacțiunea obiectelor, identificând mesajele schimbate între obiecte ca
răspuns la uneveniment, împreună cu secvența mesajelor. Diagramele secvențiale cuprind
obiectele care facparte dintr-o anumită colaborare și descriu secvența de stimuli transmiși între
obiecte în cadrulunei interacțiuni. Ele cuprind și dimensiunea temporală, deoarece fiecărui obiect
îi corespunde olinie de viață, trasată vertical sub numele obiectului.

Deci diagrama de secvențe va avea următoarele elemente:

1. Obiectele - care vor fi rerezentate la fel ca și încazul diagramei de

obiecte, darcompartimetul pentru atribute este întodeauna suprimat(deci numele
obiectului esteîncadrat într-un dreptunghi, pentru obiectele concurente, este îngroșată)

2. Linia de viață a obiectului - este reprezentată în mod obișnuit printr-o linie

verticalăîntreruptă, ce coboară din dreptunghiul obiectului. În intervalul de timp în care

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 17 | Page
 obiectul este activ, spre exemplu cînd efectuiază o operațiune, linia întreruptă este
înlocuită cu undreptunghi vertical foarte subțire.

3. Stimuli - pot constitui semnale, apeluri de operații, crearea sau distrugerea unui obiect.
Săgețile stimulilor sunt orientate sunt orientate în sensul în care aceștia sunt
transmiși,fiind însoțite de o etichetă. Aceasta cuprinde, în general, numele și, dacă este
cazul,argumentele sale; poate fi prezentă și o condiție pentru transmiterea stimulului.

Timpul în diagrama de secvențe curge de sus în jos iar stimulii sunt reprezentați prin
săgețietichetate, de la linia de viață a obiectului transmițător către linia de viață a celui receptor.

Relația sincronă - de regulă, suspendă execuția de mai departe a procesului atîta timp cît
se așteaptă o confirmare sau un răspuns de la receptor. Acestea sunt reprezentate cu
ajutorul unei săgeți cu vîrful plin.

Relația asincronă - mesaje la care nu se așteaptă un răspuns anumit, corespunzător,

execuția procesului nu este întreruptă. Mesajele asincrone sunt reprezentate cu ajutorul
unei săgeți cu vîrful deschis.

Tipuri de stereotipuri

Un mesaj reflectă fie un o apelare de operație (metodă, funcție, procedură) și începutulexecuției

acesteia sau transmiterea și recpția unui signal. Cînd mesajele reprezintă un apel deoperație,
argumentele mesajului sunt și argumente ale operației. Cînd mesajul reprezintă unsignal,
argumentele mesajului sunt atributele signalului.

În dependență de tipul acțiunii care acenerat mesajul, mesajele se impart în:

1. mesaje sincrone

2. mesaje asincrone

3. de creare

4. de distrugere

5. de răspuns

Proiectarea unei diagrame a cazurilor de utlizare urmărește scopurile următoare:

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 18 | Page
- Determinarea limitelor commune și a contextului domeniului de modelare la etapele
inițiale de proiectare a unui sistem

- Formularea cerințelor commune către comportare funcțională a sistemului proiectat

- Elaborarea modelului initial conceptual al unui sistem pentru detalierea de mai tîrziu în
forma modelelor logice și fizice

- Pregătirea documentației inișiale pentru interacțiunea elaboratorilor unui sistem cu

clienții și utilizatorii

Esenţa acestei diagrame constă în faptul că: sistemul proiectat se reprezintă ca o colecţie de
entităţi şi actori care colaborează cu sistemul cu ajutorul aşa numitor cazuri de utilizare.

Cazul de utilizare deteremina o succesiune de actiuni care trebuie sa fie executate de catre
sistemul proiectat la colaborarea lui cu un anuimt actor.

Scopul cazului de utilizare constă în determinarea aspectului terminal sau fragmentului de

comportare a unei entităţi fără desfăşurarea structurii interne a acestei intităţi. În calitate de aşa
entitate poate fi un sistem iniţial sau un element al modelului care dispune de comportament
propriu, precum este subsitemul sau clasa în modelul unui sistem.

Actorul reprezintă orice entitate externă sistemului modelat, care colaborează cu sistemul şi
utilizează posibilităţile lui funcţionale pentru atingerea anumitor scopuri şi pentru rezolvarea
problemelor particulare.

Interfaţa (interface) specifică parametrii modelului care sunt vizibili din afară fără indicarea
structurii lor interne. În limbajul UML interfaţa este clasificatorul care caracterizeză numai o
parte limitată a comportării unei entităţi modelate.

Între interfață și caz de utilizare putem folosi 2 relații: asocierea și dependența

Relațiile diagramei caz de utilizare:

- Actor – Actor: dependență, generalizare

- Actor – Caz de utilizare: asociere

- Caz de utilizare – Caz de utilizare: dependența (stereotipuri: „include”, „extend”,

„depends”)

Implementare, rezultate practice:

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 19 | Page
 1. Diagrama de secvențe - Interacțiunea dintre utilizator și aplicație bancară

Pentru a putea accesa un sistem informational ales utilizatorul trebuie întâi de toate să
lanseze aplicația, prin intermediul interfeței acesteia. După ce aplicația bancară se lansează cu
succes trebuie să introducem datele de logare, după deja vom avea acces la cont.

Figure 6. Interacțiunea dintre utilizator și aplicație bancară

2. Diagrama de secvențe<<Interacțiunea dintre utilizator, aplicație bancară și baza de date>>

Utilizatorul în sistemul informational ales poate să efectueze diverse modificări prin
intermediul aplicației bancare, fără a se prezenta la bancă. Utilizatorul poate să efectueze diverse
funcționalități de achitare, stergere, modificare date, tranzactii, direct din aplicație.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 20 | Page
 Figure 7. Interacțiunea dintre utilizator, aplicație bancară și baza de date

3. Diagrama de secvențe - Interacțiunea dintre utilizator și servicii oferite

Figure 8. Interacțiunea dintre utilizator și servicii oferite

4. Diagrama de secvențe - Interacțiunea dintre utilizator, cont utilizator, servicii oferite și
aplicație bancară

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 21 | Page
 Figure 9. Interacțiunea dintre utilizator, cont utilizator, servicii oferite și aplicație bancară

În figura 9 este prezentată diagram de secvență interacțiunea dintre utilizator, cont

utilizator, servicii oferite și aplicație bancară. Aici utilizatorul deschide aplicatia, se loghează în
cont, și efectuează achitare online.

2.3.3. Diagrama de colaborare

Considerații teoretice
_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 22 | Page
Un obiect este un concept, o abstractie sau un lucru avind limite foarte clare si un sens precis in
contextul problemei studiate. Fiecare obiect are o identitate si poate fi distins de celelalte
Un obiect în UML reprezintă o entitate care are atât atribute, cât şi un comportament, dat

de metodele aferente acestuia. Astfel, obiectele în UML:

a. Sunt entităţi care au atît atribute cît şi o comportare: de exemplu, un tip de date abstract
împreună cu operaţiile definite pentru acesta;

b. Comunicarea inter-obiecte trebuie văzută ca o transmitere de mesaje între două obiecte;

c. Sunt instanța unor clase

Diagrama de colaborare este o diagramă de interacţiuni care pune accentul pe organizarea

structurală a obiectelor care participă la interacţiune.

Diagrama de colaborare poate conţine:

a) obiecte;

b) legături între obiecte;

c) mesajele prin care obiectele comunică.

Diagramele de colaborare au multe asemănări cu diagramele de secvenţă, exprimând aceleaşi

informaţii dar într-un alt format. Pot fi create la nivele diverse de detaliu şi în diferite stadii de
dezvoltare a procesului software. Deoarece au un conţinut similar, pot fi folosite pentru
generarea diagramelor de secvenţă şi viceversa. Diferenţa semnificativă faţă de diagrama de
secvenţă este aceea că diagrama de colaborare arată explicit legăturile dintre obiecte. De
asemenea, la diagrama de colaborare timpul nu are o dimensiune explicită.

Din acest motiv, ordinea în care sunt trimise mesajele este reprezentată prin numere de
secvenţă. Mesajele dintr-o diagramă de colaborare sunt reprezentate de un set de simboluri care
sunt asemănătoare celor utilizate în diagrama de secvenţă, dar cu câteva elemente adiţionale
pentru Diagrama de colaborare și diagrama de strucură sunt numite și digrame de interacțiune.
Diagrama de Secvență accentuează factorul timp, arătînd cum au loc interacțiunile în timp ce
Diagrama de Colaborare accentuează contextul și organizarea de ansamblu a obiectelor care
interactionează. De asemenea, Diagrama de Secvență este aranjată în funcție de factorul timp, iar
Diagrama de Colaborare în funcție spațiu.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 23 | Page
 O diagramă de colaborare la nivelul instanțelor este un graf, avînd ca noduri obiectele
participante la colaborare și ca arce legăturile dintre ele, însoțite de stimulii transmiși prin
intermediul acestora. Obiectele sunt reprezentate la fel ca în diagramele de obiecte, prin
dreptunghiuri ce conțin numele obiectului subliniat, dar fără a ilustra valorile atributelor. Se
poate prezenta și rolul obiectului în colaborare, folosind următoarea notație generală:

NumeObiect'/'NumeRolClasificator':'NumeClasificator['.'NumeClasificator]*

Caracterul '*' poate apărea în colțul din dreapta sus al dreptunghiului, fiind un indicator
pentru multiplicitatea obiectelor ce joacă același rol. Aceste elemente sunt opționale; pentru
specificarea unui obiect este necesar să existe cel puțin unul dintre numele de mai sus, neapărat
subliniat.

Există , de asemenea, trei restricții standard pentru obiectele sau legăturile crate în timpul
execuției: {new} pentru elementele nou create, {destroyed} pentru elementele distruse și
{transient} pentru elementele tranzitorii - atatît create, cît și distruse pe parcursul aceleiași
interacțiuni. Obiectele tranzitorii pot reprezenta argumente ale procedurilor sau variabilelor
locale. a marca secvenţierea şi recurenţa.

Legăturile apar ca linii, avînd la capete, opțional, numele olului de asociațiecorespunzător; pot
apărea și auto-legături, marcate prin stereotipul << self >>. Stimulii se reprezintă prin săgeți
mici, atașate legăturilor și indicînd navigabilitatea diagramei. Acestea sunt însoțite de cîte o
etichetă avînd sintaxa:

Predecesori Condiție Secvențialitate

ValoareReturnată:=NumeStimul ListăArgumente

Condiționarea unui stimul se efectuiază printr-o condiție trecută între paranteze drepte, precum
[a>1] StimulCondiționat.

Secvențialitatea constă dintr-o secvență de numere sau nume, ce pot fi urmate de indicatori de
recurență. Pentru un flux de control procedural, se efectuiază o imbricare conform apelurilor
imbricate de proceduri cum ar fi: vr:= procedură(param). O execuție iterativă se specifică prin
sintaxa '*''['clauză-iterare']', rezultînd etichete precum mesaj*[I:=1..n].

Standardul UML prevede 3 tipuri de săgeți pentru reprezentarea stimulilor, prezentate în tabelul
de mai jos:
_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 24 | Page
Implementare, rezultate practice:

1. Diagrama de colaborare - Transfer bancar ( Nivel de exemple)

Mai jos avem prezentată de colaborare nivel de exemplepentru transfer bancar în cadrul unei
aplicații bancare. Întâi de toate urilizatorul acceseaza aplicația, selecteaza operatiunea necesară,
și o transmite către serviciul bancar, după care acesta prelucrează datele și oferă răspuns.

Figure 10. Transfer bancar ( Nivel de exemple)

2. Diagrama de colaborare- Autentificare în aplicația bancară ( Nivel de exemple)

În figura 11 este reprezentată diagrama de colaborare nivel de exemplu,pentru procesul de

autentificare în aplicație bancară. În primul rând, utilizatorul lansează aplicația bancară prin
intermediul dispozitivului electronic. Apoi aplicația trimite o solicitare către baza de date, care
returnează un formular pentru autentificare. La pasul 4, utilizatorul introduce datele de logare,
apoi aplicația trimite datele către baza de date, după care aplicația bancară verifică integritatea
datelor și solicit din baza de date informația pentru utilizator care conține date logare pentru
utilizator. După care datele sunt trimise către aplicație, dizpozitiv și mai apoi se afișează contul
bancar.
_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 25 | Page
 Figure 11. Autentificare în aplicația bancară ( Nivel de exemple)

3. Diagrama de colaborare - Autentificare ( Nivel de specificare)

În figura 12 este reprezentata diagrama de colaborare nivel de specificare - Autentificare. În

figura dată se poate observa interactiunea dintre actor și obiect. Pentru a se autentifica Admin-ul
folosește un dispozitiv electronic, și anume aplicația bancară necesară, după care introduce date
de acces : Login și Parola.

Figure 12. Autentificare ( Nivel de specificare)

4. Diagrama de colaborare – Transfer bancar ( Nivel de specificare)

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 26 | Page
 În figura 13 este reprezentată diagrama de colaborare nivel de specificare – Transfer bancar
prin intermediul aplicației bancare. În figura dată se poate observa interacțiunea dintre persoana
fizică și persoana juridică. Utilizatorul 1 transferă banii către Utilizatorul 2, acesta din urmă
semnalizând transferal(primirea).

Figure 13. Transfer bancar ( Nivel de specificare)

2.3.4. Diagrama claselor

Considerații teoretice:

Modelarea unui sistem presupune identificarea lucrurilor care sunt importante pentru
acesta și care formează vocabularul sistemului. În UML, toate aceste lucruri sunt modelate
folosind clase.

O clasa înseamna descrierea unei mulțimi de obiecte care au în comun aceleași atribute, operații,
relatii și semnificație.
În diagrame, clasa este reprezentată ca un dreptunghi cu un chenar solid, împărțit prin linii
orizontale în 3 secțiuni:

1. Secțiunea de sus (secțiunea de nume) conține numele clasei și alte proprietăți generale (în
special, stereotipul).

2. Secțiunea din mijloc conține o listă de attribute

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 27 | Page
 3. În partea de jos este o listă de operații de clasă care reflectă comportamentul acesteia
(acțiuni efectuate de clasă).

Diagramele de clase sunt folosite pentru a specifica structura statica a sistemului, adica ce clase
exista în sistem și care este legatura dintre ele.În UML, o clasa este prezentata ca un dreptunghi
in interiorul caruia se scrie numeleacesteia.Fiecare clasa este caracterizata printr-o multime
deoperatiisiatribute.

Un atribut reprezinta o proprietate a unei clase. Atributele descriu datele continute de

obiectele din clasa respectiva. Pentru fiecare atribut trebuie specificat tipul acestuia.

Tipurile folosite pot fi tipuri de baza sau clase. Pentru fiecare atribut pot fi specificate
vizibilitatea, multiplicitatea si valoarea initiala. Din punct de vedere al vizibilitatii, atributele pot
fi publice, private sau protejate, marcate cu '+', '-' si respectiv '#':

a. atribute publice: pot fi accesate de orice alta clasa

b. atribute private: pot fi accesate de alte clase

c. atribute protejate: pot fi accesate doar de subclasele care descind din clasa
respective

In principiu, este bine ca, in masura in care este posibil, atributele sa fie declarate private,
conform principiului incapsularii.

Operațiunile implementează comportamentul specific clasei. O operațiune are trei părți -

nume, parametri și tip de returnare.

Parametrii sunt argumentele primite de operația „input”. Tipul de returnare se referă la rezultatul
acțiunii operației.

Într-o diagramă de clasă, puteți afișa atât numele operațiunilor, cât și numele operațiilor,
împreună cu parametrii și tipul de returnare. Pentru a reduce volumul de lucru al diagramei, este
util să afișați doar numele operațiunilor pe unele dintre ele, iar pe altele semnătura lor completă.

Există patru tipuri diferite de tranzacții de luat în considerare:

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 28 | Page
 1. Operațiuni de implementare;
2. Operațiuni de control;
3. Operațiuni de acces;
4. Operatii auxiliare.
Operațiuni de implementare
Operațiunile de implementare implementează unele funcții de afaceri. Astfel de operațiuni pot fi
găsite examinând diagramele de interacțiune. Diagramele de acest tip se concentrează pe
funcțiile de business, iar fiecare mesaj din diagramă poate fi asociat, cel mai probabil, cu o
operațiune de implementare.

Operațiuni de control
Operațiunile managerului controlează crearea și distrugerea obiectelor. Constructorii de clasă și
destructorii se încadrează în această categorie.

Operațiuni de acces
Atributele sunt de obicei private sau protejate. Cu toate acestea, alte clase trebuie uneori să-și
vadă sau să-și schimbe valorile. Există operațiuni de acces pentru aceasta. Această abordare face
posibilă încapsularea în siguranță a atributelor într-o clasă, protejându-le de alte clase, dar totuși
permite accesul controlat la ele. Este o practică standard să creați operațiuni Get și Set pentru
fiecare atribut de clasă.

Operatii auxiliare
Operațiile helper sunt acele operațiuni ale unei clase de care are nevoie pentru a-și îndeplini
responsabilitățile, dar despre care alte clase nu ar trebui să știe nimic. Acestea sunt operațiuni
private și protejate ale clasei.

O relație este o relație semantică între clase. Permite unei clase să învețe despre
atributele, operațiile și relațiile unei alte clase. Cu alte cuvinte, pentru ca o clasă să poată trimite
un mesaj către alta într-o diagramă de secvență sau o diagramă de cooperare, trebuie să existe o
relație între cele două.

Există patru tipuri de relații care pot fi stabilite între clase:

a. asocieri,
b. dependențe,
c. agregari,

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 29 | Page
 d. generalizări.
Asocierea este legătura semantică dintre clase. Ele sunt desenate pe diagrama de clasă ca o
linie obișnuită.

Figura 14. Asociația de comunicare

Asociațiile pot fi bidirecționale, ca în exemplu, sau unidirecționale. În UML, asociațiile

bidirecționale sunt desenate ca o linie simplă fără săgeți sau cu săgeți pe ambele părți. Într-o
asociere unidirecțională, este reprezentată o singură săgeată care arată direcția acesteia.
Asociațiile pot fi reflexive. Asocierea reflexivă presupune că o instanță a unei clase
interacționează cu alte instanțe ale aceleiași clase.

Dependența de comunicare

Relațiile de dependență reflectă și relația dintre clase, dar sunt întotdeauna unidirecționale și
arată că o clasă depinde de definițiile făcute în cealaltă. De exemplu, clasa A folosește metode
din clasa B. Apoi, atunci când clasa B se schimbă, trebuie să faceți modificările corespunzătoare
în clasa A.

Dependența este reprezentată ca o linie întreruptă între două elemente de diagramă, iar elementul
ancorat la sfârșitul săgeții este considerat a fi dependent de elementul ancorat la începutul acelei
săgeți.

Figura 15. Dependenta de comunicare

Agregările sunt o formă mai strânsă de asociere. Agregarea este o legătură între un întreg
și o parte a acestuia. De exemplu, este posibil să aveți o clasă pentru Mașină, precum și clase
pentru Motor, Anvelope și clase pentru alte părți ale mașinii. Ca rezultat, un obiect din clasa
Mașină va consta dintr-un obiect din clasa Engine, patru obiecte din Anvelope etc.

Agregațiile sunt vizualizate ca o linie cu un romb pentru o clasă care este un întreg:

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 30 | Page
IMPLEMENTARE, REZULTATE PRACTICE:

1. Diagrama de clasă <Utilizatorii aplicației bancare>

În figura de mai jos avem prezentată diagram de clasa <Utilizatori>, în care avem
prezentate clasele pentru tipurile de utilizatori care pot folosi aplicația bancarp, și anume:

1. Utilizatorul înregistrat, care are cont deja creat,

2. Utilizator nou, care urmează să se înregistreze în aplicație,

3. Amin, persoană demnă să modifice datele unui utilizator al aplicației.

Aceste clase sunt clase moștenite de la clasa Utilizator Aplicatie, după care apare o clasă noua
care se numește compozitie, și anume clasa <Cont>, ea indică că această clasă este parte
componentă a clasei Utilizator înregistrat, și că fără ea clasa de mai sus nu are sens.

Figura 16. Utilizatorii aplicației bancar

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 31 | Page
2. Diagrama de clasă <Gestionarea Serviciilor și Achitarea Facturilor de către Utilizator>

În această diagramă avem reprezentat modul de gestiunare a serviciilor si facturilor, care

pot fi achitate prin intermediul aplicației bancare. Respectiv in dependență de anumite zile, și
servicii generale, acestea pot apărea în contul din aplicație și urmează să fie achitate, la fel intr-
un termen stabilit. Serviciile si facturile se modifica de la o dată, la alta. Cand utilizatorul
accesează o anumită factură, el primeste detalii și suma care urmează a fi achitată, și căsușa unde
trebuie să plaseze datele unei eventuale facturi noi. Prin urmare aceta mai primeste si un bon de
confirmare a plații.

Figure 17. Gestionarea Serviciilor și Achitarea Facturilor de către Utilizator

3. Diagrama de clasă <Achitarea unei facturi >

În figura 18 avem prezentată diagrama de clasă pentru achitarea unei facturi prin
intermediul aplicației bancare. Până la achitarea finală, aceasta trece prin anumite procese de
verificare al contului bancar ( de exemplu dacă avem suma necesară pentru a efectua
tranzactia), și dacă cardul coincide cu datele din cont.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 32 | Page
 Figure 18. Achitarea unei facturi

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 33 | Page
 2.3.5. Diagrama stărilor

CONSIDERAȚII TEORETICE

O diagramă de stare modelează viaţa unui obiect prin stările sale şi schimbările de stare
care au loc pe parcursul vieţii. Schimbările de stare sunt determinate de evenimente. Diagramele
de stări modelează efectul acestor interacţiuni asupra stării interne a fiecărui obiect. Mesajele din
diagramele de interacţiune sunt evenimente care schimbă starea internă a obiectelor. Examinând
diagramele de interacţiune se pot descoperi care sunt obiectele care ar trebui modelate prin
diagrame de stări. Multe obiecte sunt create, referite şi apoi distruse. Ele au o singură stare
intermediară şi deci nu are sens modelarea lor printr-o diagramă de stări. Alte obiecte, însă, care
răspund la mesaje în mod diferit pe parcursul vieţii, se pot preta la această modelare.

Figure 29. Simbol Stare inițială și stare finală

Starea iniţială identifică starea în care obiectul este creat. Cu toate că notaţia pentru
starea iniţială include numai cercul plin, în practică starea iniţială include şi săgeata care pleacă
din ea şi starea în care obiectul este creat.

La sfârşitul vieţii (activităţii) sale, obiectul atinge starea finală, din care nu mai poate
ieşi. Starea finală are toate proprietăţile unei stări, cu o excepţie: nu poate avea tranziţii de ieşire.
Numele stării de ieşire este specificat lângă simbolul grafic al stării finale. O
simplă tranziţie reprezintă o relaţie între două stări consecutive, indicând faptul schimbării unei
stări cu o alta. Prezenţa obiectului modelat în prima stare va efectua anumite acţiuni, dar trecerea
în starea a doua se va produce atunci când anumite acţiuni vor fi terminate şi după îndeplinirea
anumitor condiţii suplimentare.

Executarea tranziţiei poate depinde nu numai de petrecerea unui anumit eveniment, dar şi
de la îndeplinirea condiţiei corespunzătoare, care se numeşte condiţie gardă. Obiectul va trece de
la o stare la alta, numai în cazul în care a apărut acţiunea indicată şi condiţia de gardă este
îndeplinită.

Stările sunt reprezentate prin dreptunghiuri rotunjite iar tranziţiile prin săgeţi deschise.
Starea iniţială şi cea finală se reprezintă astfel:

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 34 | Page
 Starea este subînțeleasă ca metaclasă abstractă ce se utilizează pentru modelarea
situațiilor separatepe parcursul careia se execută careva condiții.

Starea compusă cu substări depuse conține 2 sau mai multe stări depuse, obiectul se
poate afla în unadin acveste stări.

Starea compusă cu substări disjuncte se utilizează pentru a modela comportamentul

obiectului întimpul căreia într-un anumit moment de timp oniectul poate să se afle într-o
singurăsubstare.

Starea compusă cu substări concurente conține două sau mai multe subautomate și care
se executăconcomitant în cadrul stării compuse

Starea activitate este un caz particular a stării. Starea activitate nu poate aveatranziții
interne fiindcă ea este elementară. Starea activitate se utilizează pentru modelarea unui pas de
executare a algoritmului sau a unui flux de control.

În limbajul UML pentru acest scop se utilizează simboluri pentru diviziune și unire a
calculelor paralele sau a fluxurilor de control. Acest simbol este o linie dreaptă analogic notației
unei tranziții în formalismul rețelelor Petri.

De regulă această linie se reprezintă printr-un segment al unei linii orizontale sau
verticale, grosimea căreia este mai mare decât grosimea liniilor în diagrama de activități.
Totodată fork (divizarea – concurrent fork) are o tranziție de intrare și mai multe de ieșire. Join
(unirea – concurrent join) invers are mai multe tranziții de intrare și numai o tranziție de ieșire.

Figure 30. Fork şi join a mai multor fluxurilor paralele de control

IMPLEMENTARE, REZULTATE PRACTICE:

1. Diagrama de stare - Efectuarea transferului bancar

În figura 21. avem prezentată diagram de stare, și anume efectuarea transferului bancar.
Avem explicați pașii pe care îi pargurge sistemul pentru a efectua transferal. Pentru a trimite
bani, este necesar ca utilizatorul să lanseze aplicația și să introduce datele de logare în system.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 35 | Page
 Dacă acestea vor fi incorecte, ne va duce iarasi la etapa inițială, iar dacă autentificarea s-a
făcut cu success, vom merge mai departe cu procedura. Si anume vom selecta transferal necesar,
dacă suma introdusă o avem pe card atunci procesul va merge spre final, dacă nu , atunci ca
rezultat vom avea eroare respinsă, si prin urmare va fi nevoie să modificăm o sumă validă în
cont.

Figure 21. Efectuarea transferului bancar

2. Diagrama de stare - Efectuarea transferului P2P prin intermediul aplicației bancar

În această figura avem prezentată diagrama de stare prin altă metodă de transfer, aici avem o
masină static in interiorul căreia am introdus anumite diagrame de stare, etapeexecutate pentru ca
transferal să fie perceput. Dacă vom obeserva avem doar un punct initial, și 3 puncte de final,
dintre care unul anulat, cu posibilă eroare, care poate să fie și modificată repetat.
_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 36 | Page
 Figure 22. Efectuarea transferului P2P prin intermediul aplicației bancar

2.3.6. Diagrama activităților

3. Diagrama de activități - Achitare comunale

În această figura avem prezentată diagrama de activitate pentru a efectua achitare servicii
comunale. Punctul initial îl conectam pentru a deschide aplicația, prin urmare aceasta va fi
conectată la blocul de decizie, de unde de ramificăm în 2 părți: pe ramura din stânga vom avea
lansarea aplicației cu success, iar in dreapta vom avea eroare de logare. Din ramura stângă vom
mai avea o parte si anume aceea de a allege serviciul de achitare comunale prin intermediul
aplicației bancare. La final printr-un bloc de decizie se unesc cele două părți și se închide
aplicația.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 37 | Page
 Figure 23. Achitare comunale

4. Diagrama de activități - Achitare abonament

În figura 24 avem prezentată diagram de activități pentru a achita serviciul abonament lunar.
Pentru asta vom lansa aplicația, si prin intermefiul barei de sincronizare fork vom conecta 3
functii, și anume: Selectarea plății, introducerea numărului și a sumei necesare, după care aceste
3 le vom conecta prin join cu căsuța achitare abonament, după care vom închide aplicația.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 38 | Page
 Figure 24. Achitare abonament

2.3.7. Diagrama componentelor

CONSIDERAȚII TEORETICE

Component – este partea fizică a sistemului care corespunde unui anumit set de
interfeţe şi asigură realizarea lor. Componenta realizează un set de interfețe și desemnează
elementele reprezentării fizice a unui model. Grafic componenta se reprezintă printr-un
dreptunghi cu anexe

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 39 | Page
 Figura 25. Componenta

Un component poate fi reprezentat la nivel de tip sau de exemplar. Deși grafic se

reprezentă la fel, regulile de notare a numelui componentului diferă puțin.
Diagrama de componente este o diagramă de implementare care modelează
dependenţele dintre componentele software ale sistemului şi entităţile care le implementează
(fişiere cod sursă, cod binar, executabile, scripturi etc.). Într-un proiect de dimensiune mare, vor
exista multe fişiere care realizează sistemul. Aceste fişiere depind unele de altele. Natura acestor
dependenţe e dată de limbajul (limbajelor) folosite pentru dezvoltarea proiectului. Dependenţele
pot exista în momentul compilării, linkeditării sau rulării. Există de asemenea dependenţe între
fişiere sursă şi cele executabile sau obiect, rezultate din primele prin compilare.

Diagrama de componente, spre deosebire de diagramele cercetate, descrie particularitățile

reprezentării fizice a unui sistem. Diagrama de componente permite determinarea arhitecturii
sistemului elaborat prin stabilirea relațiilor de dependență între componentele programului, în
calitate de care poate fi codul inițial, binar și executabil. În mai multe medii de dezvoltare un
modul sau componenta corespund unui fișier. Relațiilor de dependență care leagă modulele sau
componentele reprezintă dependența analogice celor ce au loc la compilarea codurilor surse.

Elementele grafice de bază al diagramei de componente sunt componentele, interfețele și

dependențele între ele.

Dependența este utilizată numai pentru reprezentarea faptului existenței acestei legături,
când modificarea unui element a modelului influențează sau duce la schimbarea altui element a
modelului. Relația de dependență în diagrama de componente reprezintă o linie întreruptă cu
săgeată orientată de la client (element dependent) la sursă (element independent).

Relația poate indica legăturile modulelor programului la etapa de compilare și la generarea

codului. În alt caz dependența poate indica existenta în componentul independent descrierea
clasei, care sunt utilizate în componentul dependent pentru crearea obiectelor respective. În

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 40 | Page
diagrama de componente dependențele pot conecta componentele și interfețele de import de
component, dar și diferite feluri de componente între sine.

Interfață se referă la un punct (loc) de interacțiune dintre două unități, dispozitive

componente etc. ale unui sistem, care este compatibil din punct de vedere hardware și software
spre ambele părți ce comunică prin el uni- sau bidirecțional. Prin analogie, sensul de interfață
poate fi uzual interpretat ca o față (suprafață) de margine, de graniță a unui element, care servește
comunicației spre și/sau dinspre alte elemente. Interfața este o parte a unui sistem de operare care
servește comunicării, facilitând aceasta.

Interfața este reprezentată în formă de circumferință, care este legat cu componentul cu ajutorul
relației de realizare. În urma căruia numele interfeței, care obligatoriu trebuie să fie scrisă cu
majusculă «I», este scrisă alături de circumferință. Semantic linia înseamnă interfața, iar prezența
interfețelor la componente înseamnă că componentul dat realizează setul de interfețe respective.

În urma elaborării sistemelor interfețele asigură nu numai compatibilitatea diferitor versiuni, dar
și posibilitatea de introducere a schimbărilor în unele pârți a programului neschimbând alte pârți
a ei. În așa fel, destinația interfețelor este mai adâncă, decât specificația interacțiunii cu
utilizatorii sistemului (actorii).

Există două feluri de legătură dintre interfețe și componente. Dacă componentul realizează o
anumită interfață, atunci această interfață este numită de export, deoarece acest component
reprezintă în el modul de serviciu pentru altele componente.

Dacă componentul utilizează o anumită interfață, care este realizată de un alt component, atunci
acea interfață pentru primul component este numită de import. Particularitățile interfeței de
import constă în aceea că în diagrama de componente această relație este reprezentată cu ajutorul
dependenței.

Nod - este element real al sistemului care reprezintă un mijloc de calcul cu un anumit
anumit volum de memorie (cu posibilităţi de stocare, prelucrare a informaţieie).

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 41 | Page
IMPLEMENTARE, REZULTATE PRACTICE:

Diagrama de componente - Aplicație bancare

În Figura 26 este reprezentata diagrama de componente pentru r aplicația

bancară, cât și componentele cu care pot inteactiona aceasta.

Figure 26. Aplicație bancare

Diagrama de componente – Cont Utilizator

În figura 27 avem prezentată diagrama de componente - Cont Utilizator, și

componentele acesteia, care pot fi effectuate, și anume: primire salariu, plata
comunale, transfer bancar, etc.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 42 | Page
 Figure 27. Cont Utilizator

Diagrama de componente – Plați lunare

Figure 28. Plați lunare

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 43 | Page
 2.3.8. Diagrama de plasare

Diagrama de plasare(diagrama de implementare), împreună cu afișarea compoziției și

relațiilor elementelor sistemului, arată modul în care acestea sunt localizate fizic pe resursele
de calcul în timpul execuției. Astfel, în diagrama de plasare, în comparație cu diagrama
componentelor, se adaugă două tipuri de entități: artefactul 1, care este implementarea
componentei 2, și nodul 3, precum și o relație de asociere între Nodurile 4, care arată că
nodurile sunt conectate fizic în timpul rulării.

Diagrama de plasare – Legătura dintre client-aplicație-server

Figure 29. Legătura dintre client-aplicație-server

În figura 29, avem prezentată diagrama de plasare este destinată vizualizării

elementelor de program și a componentelor care există doar în stadiul de execuție. În acest
caz, sunt reprezentate numai componentele programului, care sunt fișiere executabile sau
biblioteci dinamice.
Diagrama de implementare conține reprezentări grafice ale procesoarelor, dispozitivelor,
proceselor și conexiunilor dintre ele. Spre deosebire de diagramele de prezentare logică,
diagrama de implementare este uniformă pentru sistem ca întreg, deoarece trebuie să reflecte pe
deplin caracteristicile implementării sale.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 44 | Page
CONCLUZII

În cadrul acestui capitol se vor prezenta realizările și obiectivele care au fost atinse în
timpul executării proiectului de an, precum și o descriere a eventualelor dezvoltări ulterioare.

Contribuții personale

Proiectul “ Analiza și Modelarea unei aplicații bancare ” se bazează pe mai multe

sisteme orientate oe obiecte și tipuri de diagrame, care ne ajută să construim un sistem bine
definit . Nivelul de prezentare este construit în așa fel ca să fie de înțeles de către toți utilizatorii
și să fie ușor de extins. Nivelul de business logic este un proiect care realizează toate operațiile
specificate de proiect, să în deplinească mai multe cerințe practice, logice și utile de către fiecare
utilizator bancar.

Rezultate obținute

Rezultatul final este o aplicație bancară, care se dorește să vină în ajutor utilizatorilor
conturilor bancare, dar și însăși a băncii. Scopul creării acestui proiect este de a oferi
utilizatorilor un mediu, sistem în care să se poata efectua diverse sarcini, funcții precum:
transferuri bancare, verificare cont, achitare facturi, rețea mobile,etc, fără a merge în oficiu,
utilizând tehnologii avansate și de actualitate.

Este un proiect ușor de extins, atât datorită arhitecturii sale , cât și a modului de
implimentare care nu necesită coduri complicate și datorită structurii cu atenție a proiectelor.

Sistemul realizat reușește să își atingă obiectivul propus, realizând cu succes și tipurile de
diagrame effectuate prin intermediul UML, În Enterprise Arhitect.

Dezvoltări ulterioare și îmbunătățiri

Odată ce aplicația bancară se va dezvolta, ceea ce se va întâmpla la sigur, vor apărea și

noi modificări în system. Modificări care bineînțeles vor fi și mai utile. Tehnologia nu stă pe loc,
mereu este în permanent, așa că pot apărea: mai multe limbi în system, transfer bancar mai sigur
nu doar în țară, dar și peste hotare, commision mai mic, achitări prin cod unic.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 45 | Page
REFERINȚE BIBLIOGRAFICE :

1. Melnic R., Sava N. Indrumar metodic “Analiza si modelarea sistemelor informationale”.

2. ”Enterprise Arhitect – Soluții” , [resursă electronică] – Regim de acces:
https://www.romsym.ro/produs/enterprise-architect/
3. ”Enterprise Arhitect” , [resursă electronică] – Regim de acces:
https://ro.theastrologypage.com/enterprise-architect
4. ”Enterprise Arhitect-Cursuri” , [resursă electronică] – Regim de acces:
https://www.nobleprog.ro/cursuri-enterprise-architecture
5. 6. ”Diagrama de colaborare” , [resursă electronică] – Regim de acces:
https://sites.google.com/site/uml4students/diagrama-de-colaborare
6. ”Introducere în UML” , [resursă electronică] – Regim de acces:
https://mkr-novo2.ru/ro/installation-and-configuration/obshchaya-harakteristika-yazyka-uml-
osnovy-unificirovannogo-yazyka-modelirovaniya.html
7. ”Enterprise Arhitect-Cursuri” , [resursă electronică] – Regim de acces:
http://en.wikipedia.org/wiki/Unified_Modeling_Language

8. ”Enterprise Arhitect-Cursuri” , [resursă electronică] – Regim de acces:

https://ro.wikipedia.org/wiki/Programare_orientat%C4%83_pe_obiecte
9. ”Enterprise Arhitect-Cursuri” , [resursă electronică] – Regim de acces:

https://samara.mgpu.ru/~dzhadzha/dis/15/200.html

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 46 | Page
 ANEXE
Anexa 1. Lista de figure

Figura 1. Model al unui sistem complex în notația UML ............................................................

12
Figura 2. Funcțiile aplicației bancare .........................................................................................
14
Figura 3. Verificare cont bancar .................................................................................................
15
Figura 4. Achitare servicii ..........................................................................................................
15
Figura 5. Transfer bancar............................................................................................................ 16
Figure 6. Interacțiunea dintre utilizator și aplicație
bancară ......................................................19
Figure 7. Interacțiunea dintre utilizator, aplicație bancară și baza de date ...............................
20
Figure 8. Interacțiunea dintre utilizator și servicii oferite .......................................................... 20
Figure 9. Interacțiunea dintre utilizator, cont utilizator, servicii oferite și aplicație bancară ... 21
Figure 40. Transfer bancar ( Nivel de exemple) ........................................................................ 24
Figure 11. Autentificare în aplicația bancară ( Nivel de exemple) ........................................... 25
Figure 12. Autentificare ( Nivel de specificare) .......................................................................... 25
Figure 13. Transfer bancar ( Nivel de specificare) ..................................................................... 26
Figura 24. Asociația de comunicare ............................................................................................
29
Figura 15. Dependenta de comunicare ....................................................................................... 29
Figura 16. Utilizatorii aplicației bancar ..................................................................................... 30
Figure 17. Gestionarea Serviciilor și Achitarea Facturilor de către Utilizator ......................... 31
Figure 18. Achitarea unei facturi ............................................................................................... 32
Figure 59. Simbol Stare inițială și stare finală .......................................................................... 33
Figure 60. Fork şi join a mai multor fluxurilor paralele de control .......................................... 34
Figure 21. Efectuarea transferului bancar ..................................................................................
35
Figure 22. Efectuarea transferului P2P prin intermediul aplicației bancar .............................. 36
Figure 23. Achitare comunale ..................................................................................................... 37
Figure 24. Achitare abonament ................................................................................................... 38
_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 47 | Page
Figura 25. Componenta ...............................................................................................................
39
Figure 26. Aplicație bancare ....................................................................................................... 41
Figure 27. Cont Utilizator ........................................................................................................... 42
Figure 28. Plați lunare ................................................................................................................ 42
Figure 29. Legătura dintre client-aplicație-server ......................................................................
43

Anexa 2. Glosar termini

Abstract Class - O clasă care nu poate fi instanțiată direct.

UML (Unified Modeling Language) - un limbaj standard pentru descrierea de modele și

specificații pentru software. Limbajul a fost creat de către consorțiul Object

Association Class - Un element de model care are atât proprietăți de asociere, cât și de clasă. O
clasă de asociere poate fi văzută ca o asociere care are și proprietăți de clasă sau ca o clasă care
are și proprietăți de asociere.
Browser Window - Fereastra spațiului de lucru în care conținutul modelului este afișat în format
„arboresc”. Afișează structuri precum pachete, diagrame și elemente de model.
Aggregation - O formă specială de asociere care specifică o relație între ansamblu (întreg) și o
parte componentă.
Call - O stare de acțiune care invocă o operație asupra unui clasificator.
CASE - Inginerie software asistată de calculator. Un instrument conceput cu scopul de a modela
și construi sisteme software.
Child - Într-o relație de Generalizare, specializarea unui alt element, părintele.
Node - Un clasificator care reprezintă o resursă de calcul în timpul execuției, care are în general
cel puțin o memorie și adesea o capacitate de procesare. Obiectele și componentele din timpul de
execuție pot locui pe noduri.
Pattern - O colaborare șablon.

_____________________________________________________________________________________
St. gr.TI-191 FR Onisim Ariadna, 48 | Page