Ministerul Educaţiei, Culturii şi Cercetării al Republicii Moldova

Universitatea Tehnică a Moldovei

Facultatea Calculatoare Informatică şi Microelectronică
Departamentul Ingineria Software şi Automatică

Proiect de curs
La disciplina

Analiza şi Modelarea Orientată pe Obiecte

Tema: Analiza şi modelarea Aplicației

Web „Comunitate”

A efectuat: st. gr. TI-172 Adașanu Gicu

A verificat: lect. univ. Melnic Radu
lect. univ. Sava Nina

Chişinău 2019
Cuprins

Cuprins .................................................................................................................................. 1
Sarcina ................................................................................................................................... 2
Introducere ............................................................................................................................. 3
Ce face o comunitate? ................................................................................................. 3
Comunităţile sunt grupuri de persoane cu un interes comun. O comunitate cu acces
deschis este disponibilă pentru alăturarea oricărei persoane din organizaţia dumneavoastră,
în timp ce calitatea de membru al unei comunităţi restricţionate este limitată la un anumit
grup. Puteţi, de asemenea, să începeţi o comunitate în organizaţie cu acces moderat,
permiţându-vă să controlaţi membrii şi să gestionaţi accesul la resursele comunităţii. ....... 3
Analiza domeniului de studiu ................................................................................................ 4
Noţiuni teoretice .......................................................................................................... 4
Introducere în limbajul UML .......................................................................... 4
1.1.1. Diagramele limbajului UML ............................................................ 7
1.2. Analiza sistemelor similare ........................................................................... 11
2 Proiectarea sistemului informaţional ........................................................................ 13
2.1. Diagramele cazurilor de utilizare .................................................................. 14
2.2. Diagramele de interacţiune............................................................................ 17
2.3. Diagramele de clasă ...................................................................................... 22
2.4. Diagramele de comportament ....................................................................... 24
2.5. Diagramele de componente ........................................................................... 27
2.6. Diagramele de plasare ................................................................................... 28
Concluzie ............................................................................................................................. 30
Bibliografie .......................................................................................................................... 31

1
 1. Sarcina

Scopul proiectului de curs:

Ca scop acest proiect ne va permite să facem cunoștință cu o metodă mai eficientă și mai simplă
pentru a proiecta diferite aplicații prin intermediul limbajului grafic UML, să studiăm tipurile de
diagrame, caracteristicile, elementele și regulile de construcție.

Sarcinile proiectului de curs:

Efectuaţi analiza şi modelarea unei aplicații web utilizând diagrame UML utilizând software-ul de
modelare Enterprise Architect.

2
 2. Introducere
O comunitate permite persoanelor care au interese comune să interacţioneze cu alte persoane.

Ce face o comunitate?

Comunităţile sunt grupuri de persoane cu un interes comun. O comunitate cu acces deschis este
disponibilă pentru alăturarea oricărei persoane din organizaţia dumneavoastră, în timp ce calitatea de
membru al unei comunităţi restricţionate este limitată la un anumit grup. Puteţi, de asemenea, să începeţi
o comunitate în organizaţie cu acces moderat, permiţându-vă să controlaţi membrii şi să gestionaţi accesul
la resursele comunităţii.

Figuta 1 – Comunitatea Ruls.ro.

3
Analiza domeniului de studiu

Înainte de a efectua oricare cercetare, proiect ştiinţific sau pur şi simplu o lucrare de laborator, este
necesar de a studia cu precauţie domeniul în care se urmează de a lucra. În primul rând, acest pas se cere
pentru a face cunoştinţă cu toate detaliile, noţiunile şi procedurile de lucru cu care se va cere de
manipulat. Totodată, pentru a putea îndeplini obiectivele propuse cu succes, este nevoie de a poseda
cunoştinţe mai aprofundate despre domeniul ales.

O analiză bună a cadrului de studiu mereu va începe cu studierea şi înţelegerea documentaţiei sau
materialului teoretic care dezvăluie esenţa sferei de activitate pentru care a fost elaborat. În cazul curent,
pentru a începe lucrul asupra proiectului de curs, este necesar, iniţial, de a studia teoria ce descrie
structura şi funcţionalitatea limbajului UML.

Noţiuni teoretice

Introducere în 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 Management Group
(OMG) care a mai produs printre altele şi standardul de schimb de mesaje intre sisteme CORBA. UML a
fost la bază dezvoltat pentru reprezentarea complexităţii programelor orientate pe obiect, al căror
fundament este structurarea programelor pe clase, ş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.
Limbajul UML este compus din entităţi şi relaţii. Numai cu ajutorul acestor două categorii de
elemente se pot construi diagramele de structură şi diagramele de comportament. Pentru a începe
studiul limbajului, este o idee bună de a face cunoştinţă, mai întâi, cu entităţile disponibile pentru
utilizare. Acestea sunt de câteva tipuri:
 Entităţi de structură;
 Entităţi de comportament;
 Entităţi de grupare;
 Entităţi de adnotare.

4
 Tabelul 1.1 – Entităţile limbajului UML

Denumire Descriere Reprezentare grafică

Entităţile de structură
Clasa UML modelează componentele
(entităţile) de interes ale unui sistem. Clasa
are instanţe, sau realizări. Aceste instanţe
sunt obiectele clasei. Prin conceptul de clasă
se descriu structura şi comportarea
obiectelor clasei. Structura conţine atributele
fiecărui obiect din clasă. Comportarea
include operaţiunile ce pot fi efectuate
asupra unei instanţe specifice (obiect).
Nume
Sintaxa specificării atributelor este
următoarea:
vizibilitate ID : tip = valoare_implicită listă atribute
unde:
vizibilitate reprezintă protecţia + vârsta : int
Clasă atributului şi poate avea una din următoarele
(Class) valori (+) public, (-) privat şi (#) protected
ID este identificatorul atributului listă metode
tip este tipul de date al acestuia
valoare_implicită – valoarea iniţială a # conectare () : void
atributului (opţională).

Sintaxa specificării metodelor este

următoarea:
vizibilitate ID (idP1 : tip1, ...) : tip_returnat
unde:
vizibilitate reprezintă protecţia metodei.
ID este identificatorul metodei
idP1, ... sunt parametri metodei
tip1, ... sunt tipurile parametrilor
tip_returnat reprezintă tipul valorii
returnate de metodă
Interfaţa descrie un set coerent de
atribute şi metode obligatorii. Ea descrie un
contract, iar oricare instanţă ce realizează
Interfaţă INume
acest contract este obligată şă realizeze toate
(Interface)
câmpurile definite în interfaţă.
sau
Declararea atributelor şi metodelor este
identică cu metoda de mai sus.

5
 <<interface>>
INume

listă atribute
+ vârsta : int

listă metode
# conectare () : void

Această diagramă prezintă

funcţionalitatea sistemului. Ea prezintă o
Caz de utilizare totalitate de acţiuni îndeplinite de sistem şi Acţiune
(Use case) care produc un impact semnificativ pentru
un anumit actor. Numele reprezintă o
acţiune.

Colaborarea descrie structura

Colaborare
elementelor care colaborează între ele şi
(Collaboration)
produc un efect corporativ.

Obiectele clasei active sunt antrenate în

Clasă activă Reprezentarea grafică este
mai multe procese şi pot iniţia acţiuni
(Active class) asemănătoare cu cea a clasei.
administrative.

Componentul reprezintă partea fizică a

Componentă
sistemului care încapsulează conţinutul şi
(Component)
manifestă un comportament propriu.

Nod Nodurile reprezintă dispozitivele fizice

(Node) sau mediile de executare a aplicaţiilor.

Entităţile de comportament

Interacţiunea reprezintă un mod de

Interacţiunea
comportare a entităţilor, care constă în
(Interaction)
schimbul de mesaje într-un anumit context.

6
 Starea este o clasă abstractă care se
utilizează pentru reprezentarea situaţiilor
Starea
abstracte ce reprezintă executarea anumitor
(State)
condiţii într-un anumit timp al ciclului de
viaţă a unui obiect.
Entităţile de grupare

Pachetul reprezintă un mecanism utilizat

Pachetul
pentru gruparea elementelor asemănătoare
(Package)
semantic şi pot fi modificate concomitent.

Entităţile de adnotare

Remarca este un element ce reprezintă un

Remarca
comentariu sau explicaţie pentru o anumită
(Note)
porţiune a diagramei.

1.1.1. Diagramele limbajului UML

Pentru a realiza oricare tip de diagramă, este necesar de combinat anumite entităţi specifice şi de a
realiza conexiunea dintre ele prin intermediul relaţiilor. În continuare vor fi prezentate categoriile de
diagrame, entităţile care sunt folosite în această diagramă şi relaţiile posibile între ele.
În general, construirea diagramelor UML este mult mai eficientă şi clară dacă se respectă o anumită
succesiune în procesul de proiectare. Aici există un anumit principiu, conform căruia o diagramă rezultă
din alta, diagrama următoare va fi ca o parte adăugătoare pentru cea curentă.

Tabelul 1.2 – Diagramele limbajului UML

Denumire Descriere Reprezentare grafică

Diagrama cazurilor de utilizare descrie un set de
acţiuni care pot fi îndeplinite în cadrul unui
sistem, în colaborare cu unul sau mai mulţi actori.
Fiecare caz de utilizare trebuie să producă un
rezultat pentru actor sau pentru un component al
Diagrama sistemului. Deseori, acest tip de diagramă este
cazurilor de Generalizarea
proiectat primul, deoarece va servi drept temelie
utilizare pentru diagramele următoare.
(UseCase) Entităţile disponibile: Cazul de utilizare,
Interfaţa, Colaborarea.
Relaţiile posibile:
Dependenţa (include)
 Generalizarea – relaţie care indică faptul că
entitatea fiu moşteneşte atributele şi
7
 metodele entităţii părinte, dar poate şi să
modifice comportamentul preluat;
În cazul dat, generalizarea poate fi aplicată
între doi actori şi între două cazuri de
utilizare. Dependenţa (extend)
 Dependenţa – relaţie semantică dintre două
entităţi, unde modificarea celei
independente duce la modificarea celei
dependente;
Aici există 4 stereotirpuri: <<depends>>,
<<include>>, <<extend>>, <<trace>>. Asocierea
Relaţia curentă se utilizează între două
cazuri de utilizare sau între un caz de
utilizare şi o interfaţă.
Stereotip <<include>> defineşte o acţiune
obligatorie, care este necesar de îndeplinit.
Stereotipul <<extend>> transmite ideea că Realizarea
nu este obligatoriu de îndeplinit acţiunea.
 Asocierea – relaţie de structură care descrie
totalitatea legăturilor între două elemente.
Asocierea poate fi unidirecţională şi
bidirecţională. Ea se utilizează doar între
actor şi caz de utilizare;
 Realizarea – relaţie specializată între 2
entităţi, unde una reprezintă specificarea,
iar a doua reprezintă implementarea. În
diagrama cazurilor de utilizare, realizarea
se utilizează între un caz de utilizare şi
colaborarea care îl realizează.

Diagrama secvenţelor este cea mai des utilizată

diagramă de interacţiune şi ideea principală a ei
este reprezentarea în timp a schimbului de mesaje
dintre obiecte. De regulă, diagrama de
interacţiune este construită în baza unui caz de
utilizare.
Diagrama de Entităţile disponibile: Obiectul, Interacţiunea.
interacţiune Tipurile de interacţiuni:
-  Sincronă – mesaj care, de regulă, suspendă
Mesaj sincron
Diagrama de execuţia de mai departe a procesului atîta
secvenţă timp cât se aşteaptă o confirmare sau un
(Sequence răspuns de la receptor. Aceasta este
diagram) reprezentată cu ajutorul unei săgeţi cu
vîrful plin; Mesaj asincron
 Asincronă - mesaj 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

8
 săgeţi cu vîrful deschis;
 Return - mesaj de răspuns unui apel de
operaţie (unui mesaj sincron). Este
reprezentat cu ajutorul unei săgeţi
întrerupte cu vîrful deschis.
Un alt element important este linia de viaţă şi
focus controlul. Cel din urmă reprezintă perioada
în care obiectul este activ.
Spre deosebire de cazul anterior, diagrama de
Diagrama de
colaborare prezintă interacţiunile dintre obiecte în
interacţiune
spaţiu. Ambele diagrame de interacţiune prezintă
-
aceeaşi informaţie, dar în moduri diferite.
Diagrama de
Aici se utilizează aceleaşi tipuri de mesaje între
colaborare
obiecte. O diferenţă semnificativă este faptul că
(Collaboration
lipseşte linia de viaţă.
diagram)
Diagramele de clase se utilizează pentru a
descrie structura statică a sistemului. Proiectând
diagrama dată, este important de ţinut cont de
faptul că metodele claselor vor fi echivalente cu
anumite cazuri de utilizare, iar relaţiile dintre
clase vor fi dictate de interacţiunile din diagrama Relaţii între clase
de interacţiune.
Entităţile disponibile: Clasa, Clasa activă,
Interfaţa.
Relaţiile posibile: Dependenţa, Realizarea,
Generalizarea, Asocierea. Vezi Diagrama
Cazurilor de utilizare.
Pentru relaţia de dependenţă există următoarele
stereotipuri:
 ”access” – clasa dependentă are acces la
atributele şi metodele clasei independente;
Diagrama de  ”bind” – conectează clasa dependentă la
clase şabloanele clasei sursă;
(Class diagram)  ”derive” – specifică o relaţie de moştenire;
 ”import” – atributele şi metodele clasei
independente vor fi copiate în cadrul clasei
dependente;
Relaţiei de generalizare îi pot fi atribuite
următoarele restricţii:
 {incomplete} – lipsesc unele clase fiu;
 {complete} – nu mai pot fi adăugate alte
clase fiu;
 {disjoin} – clasa fiu are o singură clasă
părinte;
 {overlapping} – clasa fiu poate avea mai
multe clase părinte.
Pentru relaţia de asociere există un caz particular
– agregarea. Acesta indică o relaţie de structură
9
 dintre partea întreagă şi partea componentă, unde
clasa componentă face parte din clasa întreagă,
dar între ele nu există o dependenţă. Pe de altă
parte, pentru agregare există un caz particular –
compoziţia. Aici, la fel este subînţeleasă o relaţie
de structură, doar că partea întreagă nu poate
exista fără acea componentă.
Diagrama de stare este utilizată pentru a modela
comportamentul sistemului. Este important ca
sistemul care se modelează să fie compus dintr-un
număr finit de stări. Acest tip de diagrame descrie
succesiunea de stări prin care trece obiectul pe
parcursul vieţii sale, dar şi tranziţiile dintre ele.
Entităţile disponibile: Starea iniţială, Starea, Diagrama de stare
Diagrama de
Starea compusă, Starea finală, Tranziţia.
comportament
În diagrama dată, toate stările pot avea una sau
-
mai multe intrări şi / sau ieşiri. Pentru a evita
Diagrama de
apariţia ambiguităţilor, au fost introduse două
stare
tipuri de tranziţii: triggered şi nontriggered.
(State diagram)
Primul tip de tranziţie va fi îndeplinit doar atunci
când va avea loc evenimentul care o defineşte şi /
sau [condiţia gardă]. Tranziţia nontriggered nu
conţine niciun element adăugător.
Stările compuse pot fi de 3 tipuri: cu substări
depuse, cu substări disjuncte şi cu substări
concurente.
Diagrama de activităţi este utilizată pentru
modelarea procesului de executare a operaţiilor.
O diferenţă majoră între aceste două diagrame de
comportament se identifică în structura stării. În
Diagrama de
timp ce starea din diagrama de stări reprezintă o
comportament
activitate a obiectului, starea-activitate din
-
diagrama de activităţi descrie execuţia unei Blocul de decizie
Diagrama de
singure operaţii din algoritmul sistemului.
activităţi
În diagrama dată poate exista doar o singură
(Activity
stare iniţială şi doar o singură stare finală, pe când
diagram)
în diagrama precedentă nu este specificată o astfel
de restricţie.
Un element foarte important în diagrama de
activităţi este blocul de decizie.
Diagrama de componente reprezintă structura
fizică a sistemului.
Diagrama de Entităţile disponibile: Clasa, Interfaţa, Clasa
componente activă, Componenta.
(Component În astfel de diagramă sunt utilizate doar două
diagram) tipuri de relaţii: Dependenţa (între două
componente sau între componentă şi interfaţă) şi Diagrama de componente
Realizarea (între componentă şi interfaţă).

10
 Diagrama dată prezintă structura arhitecturală a
sistemului, evidenţiind dispozitivele de calcul.
Diagrama de
Entităţile disponibile: Interfaţa, Componenta,
plasare
Nodul.
(Deployment
Relaţiile sunt asemănătoare cu cele ale Diagrama de plasare
diagram)
diagramei precedente, dar apare şi asocierea între
noduri.

1.2. Analiza sistemelor similare

Sistemul ales, şi care urmează a fi proiectat reprezintă o unealtă perfectă pentru dezvoltatori şi
utilizatori. Însă în dependenţă de tipul persoanei, astfel se împart şi tipurile de software. Astfel pentru
dezvoltatori, există o multitudine de soft-uri care ar ajuta la îndeplinirea sarcinii propuse. Dacă încercăm
să căutăm FTP pe motorul de căutare google.com, vom observa că rezultate sunt destul de multe, însă ca
şi firea omului, primul rezultat se consideră cel mai bun, şi anume aplicaţia FileZilla.

Următorul pas ce necesită efectuat este descărcarea şi instalarea clientului, după care ne întâlneşte
interfaţa instrumentului (Figura 1.1).

Figura 1.1 – Interfaţa aplicaţiei FileZilla

Pentru a trece la următorul pas, şi anume de ce are nevoie un dezvoltator este anume conectarea la un
server cu anumite credenţiale. Indiferent de amplasarea acestui server pe glob, este activ sau nu, aplicaţia
va încerca să se conecteze la datele serverului introduse (Figura 1.2), iar rezultatul conexiunii se va putea
observa la consolă (Figura 1.3).

11
 Figura 1.2 – Interfaţa pentru conectarea la un server

Figura 1.3 – Mesajul la conectarea cu succes la un server

Datorită simplităţii şi performanţei ridicate al acestei aplicaţii, manipularea serverului de la distanţă

este una rapidă, efectivă dar şi plăcută la utilizare.

12
 2 Proiectarea sistemului informaţional
Conform temei alese, aceasta reprezintă un sistem delicat în plan de securitate cât şi de eficienţă. Iar
pentru ca tematica este cam neobişnuită a fost necesar de studiat diferite surse externe pentru o înţelegere
mai bună a acestui sistem, pentru a prevedea absolut toate tipurile de acţiuni şi evenimente.
După cum am spus mai sus, în timp ce căutăm termenul FTP în motorul de căutare Google, am putut
reţine faptul că majoritatea instrumentelor pentru manipularea fişierelor externe conţin la denumire acest
termen (CoreFTP, SmartFTP etc), deci s-a decis că pentru proiectul curent să-i fie atribuită denumirea de
Nothing FTP.
Următorul pas fiind la proiectarea sistemului este întocmirea sarcinilor tehnice posibile ale aplicaţiei.
Această întocmire este una importantă pentru ca ulterior să fie ca ghid în proiectarea sistemului însuşi.
Sarcina tehnică pentru aplicaţie:
 Adăugarea unei conexiuni noi;
 Conectarea la un server;
 Manipularea unui fişier de pe server;
 Încărcarea unui fişier pe server;
 Încărcarea fişierelor folosind coada
 Afişarea fişierelor locale/de pe server;
 Manipularea datelor locale;
 Actualizarea aplicaţiei;
 Accesarea setărilor din aplicaţie;
 Editarea datelor private;
 Setarea permisiunilor pentru un fişier/dosar;

În continuare, pentru proiectarea sistemului, va fi utilizată aplicaţia Enterprise Architect - instrument

de modelare în limbajul UML. La capitolul dat, absolut toate componentele sistemului vor fi reprezentate
prin opt tipuri de diagrame diferite, care, la rândul lor, vor oferi diverse tipuri de informaţie.

Pentru a putea realiza sarcina propusă, este necesar, întâi de toate, de a studia şi a însuşi noţiunile
teoretice care ţin de principiile şi regulile de modelare a diagramelor UML. Este foarte important de a
stăpâni acest limbaj la un nivel mai avansat, pentru a evita greşelile logice şi sintactice.

13
 2.1. Diagramele cazurilor de utilizare
Pentru elaborarea diagramelor Use-Case în Enterprise Architect a fost selectată tema: modelarea unui
FTP(File Transfer Protocol) în programul FileZilla. S-au elaborat 5 diagrame caz de utilizare:

1. Diagrama Principală
2. Diagrama Gestionare Site-uri
3. Diagrama Conectare Rapidă
4. Diagrama Gestionare Fişiere Locale
5. Diagrama Actualizarea Aplicaţie

Figura 2.1 – Diagrama de bază al aplicaţiei

În Figura 2.1 este reprezentat Actorul - (Userul) care se foloseşte de programa FileZilla ce are
legătură cu cazurile de utilizare prin relaţia de asociere. Din diagramă se înţelege că userul poate să
îndeplinească următoarele acţiuni cum ar fi: folosirea managerului de site-uri, conectarea rapidă la un
server, interacţiunea cu fişierele locale şi actualizarea aplicaţiei.

14
 Figura 2.2 – Fereastra pentru managerul de siteuri

În Figura 2.2 este reprezentat cazul de utilizare pentru Manage Site Manager, ce se descrie printr-o
relaţie de colaborare cu stereotipurile „extend”, iar celelalte UC-uri se folosesc de relaţii precum,
asocierea, generalizarea şi colaborarea.

Pentru a crea o înscriere a unui site, user-ul e nevoit să facă anumite acţiuni obligatorii pentru
îndeplinirea acestei proceduri: trebuie să aleagă un tip de protocol valid, să introducă numele de host,
portul acestuia, să aleagă tipul de criptare, apoi urmează modul de logare, acesta poate fi anonim sau
normală, la care este nevoie de introdus datele precum username-ul şi parola, eventual putem adăuga
comentarii la discreţia noastră, şi în final pentru a salva aceste date, facem click pe butonul de save.

Pentru a modifica o înscriere deja existentă, paşii enumeraţi mai sus sunt fix aceeaşi, cu excepţia că
în câmpurile goale se vor completa cu datele iniţiale.

Pe lângă procedurile enumerate mai există şi conectarea la o înscriere deja existentă sau chiar şi
ştergerea acesteia, fiind într-o relaţie de colaborare cu stereotipul „extend”.

15
 Figura 2.3 – Procedura de conectare rapidă

În Figura 2.3 sunt reprezentate datele pe care utilizatorul trebuie să le introducă pentru a efectua
această conectare rapidă. În acest caz toate acţiunile de conectare rapidă sunt obligatorii, astfel fiecare
câmp trebuie completat pentru realizarea acestei proceduri. Astfel toate aceste acţiuni de completare şi de
conectare se află în relaţie de colaborare cu stereotipul „extend” faţă de UC-ul „Quickconnect”.

Figura 2.4 – Procesul de manipulare a datelor locale

16
 În Figura 2.4 sunt reprezentate UC-urile care apar atunci când utilizatorul vrea să manipuleze
fişierele, folderele locale, aceasta reprezintă o trăsătură a aplicaţiei.

Ca şi orice alt File Browser, user-ul poate să încarce pe host, să acceseze folderul, să deschidă,
editeze, şteargă, redenumească fişiere, şi alte manipulări cu datele. Odată ce aceste funcţii sunt la discreţia
user-ului, relaţia dintre aceste stereotipuri cu procesul de manipulare a datelor locale este una de
colaborare cu stereotipul „extend”.

Figura 2.5 – Procesul de actualizare a aplicaţiei

În Figura 2.5 este reprezentat UC-ul „Update Application” cu alegerile pe care le poate face user-ul.
Acesta poate să vadă ce este nou în actualizarea curentă, şi desigur să actualizeze aplicaţia. Între aceste
acţiuni şi procesul de actualizare există relaţia de colaborare cu stereotipul „extend”. Astfel orice acţiune
dorită este la discreţia user-ului.

2.2. Diagramele de interacţiune

Diagramele de interacţiune pot fi proiectate în două tipuri: de secvenţă şi de colaborare. De la început
se vor analiza diagramele de secvenţă.
Pentru acestui tip de diagrame s-au elaborat următoarele:
 Adăugarea unei conexiuni noi
 Conectarea la un server
 Manipularea unui fişier extern
 Încărcarea unui fişier pe server

17
 Figura 2.6 –Adăugarea unei conexiuni noi
În figura 2.6 este reprezentată diagrama de secvenţă pentru adăugarea unei noi conexiuni, salvarea
acesteia în baza de date a aplicaţiei, şi ulterior de folosit când vom avea nevoie, fără a introduce din nou
datele.

Figura 2.7 – Conectarea la un server

În figura 2.7 este reprezentat actorul(Userul) care efectuează o conectare rapidă la server, primind ca
răspuns reuşita operaţiei. Toate aceste acţiuni au loc prin intermediul aplicaţiei şi a interfeţei acesteia.

18
 Figura 2.8 – Manipularea unui fişier de pe server
În această diagramă de secvenţă, utilizatorul, se loghează la serverul dorit, introducând datele de
acces, care sunt verificate de sistem pentru veridicitatea acestora, daca există aşa date pe serverul dorit, se
trimite ca răspuns aceasta utilizatorului. Odată ce are acces la server, userul poate să aleagă orice fişier de
pe server, care mai apoi să îl downloadeze. De aici, utilizatorul poate să-l editeze şi să-l salveze, ca mai
apoi acest fişier este transmis prin intermediul aplicaţiei serverului, acesta validează fişierul pentru a nu fi
corupt, iar odată ce este valid, se înlocuieşte cu cel existent, iar ca răspuns userului se trimite un mesaj de
succes.

19
 Figura 2.9 – Încărcarea unui fişier pe server
În Figura 2.9 este reprezentată diagrama de secvenţă pentru atunci când userul doreşte să încarce un
fişier neexistent pe server, pentru aceasta are nevoie de a se autentifica pe server cu credenţialele corecte.
Apoi acest fişier este transmis cu ajutorul aplicaţiei serverului, care mai apoi este validat, iar dacă acesta
se dovedeşte a fi valid se înscriu toate datele din fişier pe server.

Acum se va analiza diagramele de colaborare. Aceste diagrame pot fi de două nivele:

a) nivel de specificare – reprezintă rolurile entităţilor şi asocierilor în colaborarea dată
b) nivel se exemplu – reprezintă interacţiunile şi legăturile în colaborarea dată

Diagrama de colaborare a nivelului de specificare reflectă rolul obiectelor care participă la

interacţiune. O schemă de colaborare de nivel exemplu arată o colecţie de obiecte şi relaţiile dintre ele.
Linkurile conţin interacţiuni suplimentare cu mesajele.

Următoarele imagini (Figura 2.10, Figura 2.11) prezintă diagrame de colaborare la nivelul de
specificare care arată succesiunea acţiunilor efectuate de utilizator şi de clientul aplicaţiei. În figura 2.10
este prezentat la nivel de specificare, relaţiile structurale dintre utilizator şi clientul aplicaţiei, în baza
adăugării unei noi conexiuni la baza de date al aplicaţiei.

20
 Figura 2.10 – Adăugarea unei server în baza de date
În figura 2.11 este prezentat, la nivel de specificare, relaţiile dintre aplicaţia FileZilla şi un server
anumit, prin afişarea tuturor fişierelor şi folderelor de pe acesta.

Figura 2.11 – Afişarea fişierelor

Următoarea imagine (Figura 2.13) prezintă diagrame de colaborare la nivel de exemplu care arată
succesiunea acţiunilor efectuate de utilizator şi de aplicaţie.

21
 Figura nr. 2.12 cuprinde reprezentarea procesului pentru încărcarea propriului fişier pe server. Astfel,
actorul alege un fişier local pentru a-l urca pe server, apoi dacă nu apare nici-un conflict de nume sau de
securitate în legătura cu acest fişier, aplicaţia începe să-i transmită serverului acest fişier bit cu bit.
Ulterior, în interfaţa aplicaţiei apare mesajul cu rezultatul acestei operaţiuni. Iar în caz că există careva
conflicte cum ar fi duplicarea fişierului, aplicaţia îi oferă utilizatorului o gamă mai largă de soluţii pentru
rezolvarea acestui conflict cum ar fi: rescriere, redenumire, ocolirea acestui fişier.

Figura 2.12 – Uploadarea unui fişier extern

2.3. Diagramele de clasă

Figura 2.13 – Sistemul ales

22
 În figura 2.13 este reprezentată diagrama de clasă pentru sistemul aplicaţiei FileZilla, pentru a
evidenţia relaţia dintre sistem şi componentele acestuia. Astfel însăşi aplicaţia(baza acesteia) depinde de
clasa FileManager, Settings, de AppHttpService pentru a face legătură cu un server anumit.

Figura 2.14 – Managerul de conexiuni din aplicaţie

În figura 2.14 este reprezentată diagrama de clasă pentru pagina FileManager, cu scopul de a duce
evidenţa, a salva conexiunile către un server anumit. Anume această salvare are loc pe o bază de date
locală unde datele se salvează sub forma clasei DatabaseData, incluzând câmpurile necesare pentru
conexiune.

Figura 2.15 – Pagina de setări

23
 În figura 2.15 este reprezentată diagrama de clasă pentru pagina cu setări a aplicaţiei. Clasa Settings
are legătură directă cu clasele Interface, Connection, Transfers, care reprezintă alte componente ale
acestei pagini.

Figura 2.16 – Utilizatorul logat

În figura 2.16 este reprezentată diagrama de clasă pentru a evidenţia tipul de utilizator a aplicaţiei
FileZilla pentru utilizatorul logat, şi anume: persoană autorizată.

Diagrama de clasă serveşte pentru a reprezenta structura statică a modelului de sistem în terminologia
claselor de programare orientată pe obiect. Diagrama de clasă poate reflecta, în special, diferitele inter-
relaţii între entităţile individuale, cum ar fi obiecte şi subsisteme, şi descrie, de asemenea, structura lor
internă şi tipurile de relaţii. Această diagramă nu indică informaţii privind aspectele temporale ale
funcţionării sistemului.

Din acest punct de vedere, diagrama de clasă reprezintă o dezvoltare ulterioară a modelului
conceptual al sistemului proiectat.

Această diagramă prezintă structura statică şi conexiunile dintre tipurile de utilizatori, precum şi între
server (baza de date). Vedem câmpurile pentru fiecare utilizator al sistemului şi funcţionalitatea
corespunzătoare fiecărui utilizator, formulate sub formă de metode, metode de server care iau informaţii
din aplicaţie şi le stochează în tabele de baze de date.

2.4. Diagramele de comportament

Diagramele de comportament pot fi proiectate în două tipuri: de stare şi de activitate. De la început se
vor analiza diagramele de stare.
24
 În figura 2.17 este reprezentată diagrama de stare pentru procedura de editare a datelor private din
aplicaţie. Odată intraţi în acel meniu, alegem varianta dorită. Ca să fie cu succes operaţiunea trebuie să
confirmăm acţiunea dorită. În caz contrat nu se va întâmpla nimic iar utilizatorul închide aplicaţia.

Figura 2.17 – Editarea datelor private

În figura 2.18 este reprezentată diagrama de stare pentru procedura de selectare a unei culori de
fundal pentru interfaţa aplicaţiei. Aici sunt enumerate toate sterile pentru a ajunge la acest rezultat. Odată
ajunşi la “Display Site Settings” alegem culoarea dorită din listă, după care putem să ne conectăm la acest
server, iar aplicaţia îşi va schimba culoarea fundalului. În caz contrar aplicaţia va afişa doar interfaţa
acesteia fără nici o schimbare.

Figura 2.18 – Selectarea unei culori de fundal la aplicaţie

Figura 2.19 reprezintă diagrama de activitate pentru procedura de setare a permisiunilor pentru fişiere
sau foldere. În diagrama dată sunt reprezentate toate activităţile elementare, necesare pentru a efectua
această procedură, acestea fiind: pornirea aplicaţiei, conectarea la un server, selectarea unui obiect,
alegerea opţiunii de setare a permisiunilor, confirmarea schimbărilor.

25
 Figura 2.19 – Setarea permisiunilor unui fişier/folder
Figura 2.20 reprezintă diagrama de activitate pentru procedura de încărcare a fişierelor cu ajutorul
cozi. În diagrama dată sunt reprezentate toate activităţile elementare, necesare pentru a efectua această
procedură, acestea fiind: deschiderea aplicaţiei, alegerea fişierului local, dacă există conexiune la vreun
server putem alege opţiunea de adăugare în coadă (în caz contrar nu vom avea acces la aceasta opţiune),
dacă mai dorim putem adăuga şi alte fişiere, selectarea opţiunii “Process Queue” din lista de aşteptare.
Dacă s-a ales vreun fişier acesta va fi încărcat pe server îndată după selectarea ultimei opţiuni.

26
 Figura 2.20 – Încărcarea fişierelor folosind Coada

2.5. Diagramele de componente

Figura 2.21 – Componentele aplicaţiei

27
 Figura 2.21 reprezintă relaţia dintre aplicaţia sistemului ales, File Transfer Protocol, şi componentele
ce conţin, respectiv funcţionalităţile acesteia, baza de date a sistemului, modelul de vizualizare a datelor şi
deja logica aplicaţiei, cea mai importantă componentă.

Figura 2.22 – Componentele paginii Site Manager

Figura 2.22 ilustrează componenţa paginii Site Manager şi se indică relaţia dintre pagină, comenzile
de bază ale utilizatorului şi înregistrare a unui server. La rândul său aceste înregistrări sunt în relaţie de
dependenţă cu baza de date prin intermediul componentelor ce fac parte din înregistrări.

Figura 2.23 – Părţile componente la procesul de încărcare a fişierului

Figura 2.23 constă în reprezentarea relaţiilor dintre părţile componente de bază a sistemului, şi anume
baza de date a sistemului, logica aplicaţiei şi fişierul de sistem. Logica aplicaţiei este dependent de baza
de date, iar pentru ca acest fişier să fie procesat mai departe, acest fişier este dependent de aceasta logică
şi de fişier al sistemului Windows.

2.6. Diagramele de plasare

Spre final a ajuns şi timpul de analizat structura de executare a aplicaţiei. Pentru ca orice utilizator să
poată avea o închipuire mai amplă despre cum decurge acest proces, şi despre cum se stabilesc relaţiile
între blocurile utilizate. În cadrul elementelor vor funcţiona următoarele obiecte: Vizualizarea Aplicaţiei
FTP, Aplicaţia FTP, Nucleul Aplicaţiei FTP şi Serverul Extern.

28
 Figura 2.24 – Elementele sistemului FTP
Figura 2.24 permite vizualizarea elementelor sistemului FTP. Diagrama conţine reprezentarea grafică
a componentelor utilizate pentru rularea acestora şi relaţiilor dintre ele. Se evidenţiază imaginea aplicaţiei,
ce permite vizualizarea şi lucrul cu datele, aplicaţia în sine ce conţine funcţionalităţile sistemului şi
reprezintă puntea dintre funcţiile de bază şi interfaţa aplicaţiei, şi deja funcţionalul principal al aplicaţiei
ce comunică cu baza de date locală din aplicaţie şi cu serverul de la distanţă ce prelucrează cererile
utilizatorului de a efectua anumite operaţii.

29
 Concluzie

Scopul acestei lucrări a fost analiza şi modelarea unui astfel de sistem ca o aplicaţie FTP File
Transfer Protocol.

Analiza ideii permitea să se determine cum ar arăta implementarea acesteia. În conformitate cu

principiile modelării, a fost creată o ierarhie şi, după caz, au fost descrise aspecte mai importante ale
sistemului.

Pentru modelare, sa folosit limba UML - un limbaj descriptiv pentru modelarea obiectului în
dezvoltarea software, modelarea proceselor de afaceri, proiectarea sistemelor şi afişarea structurilor
organizaţionale.

În prima etapă, au fost modelate cele mai importante funcţii ale sistemului pentru utilizator, descriind
astfel toate funcţionalităţile necesare şi posibile. Apoi a fost luată în considerare interacţiunea obiectelor
în timp, în acest stadiu au apărut diagrame de secvenţă. Următorul pas a fost de a rafina proprietăţile,
componentele individuale ale aplicaţiei. Au fost create diagrame de clasă, care arată relaţiile dintre clase,
atributele lor şi proprietăţile. Mai mult, s-au evidenţiat diferite procese care au apărut în timpul
funcţionării aplicaţiei. Acestea au fost mapate folosind o maşină de stare finită în diagramele de stare.
Procesele algoritmice au fost reprezentate pe diagrame de activitate. În acest stadiu, comportamentul
sistemului a fost determinat, descrierea structurii sale logice a fost finalizată. La finele realizării s-a
modelat din punct de vedere fizic. A fost făcută o diagramă a componentei care arată dependenţa
componentelor şi o diagramă de implementare.

În urma efectuării acestui proiect, am ajuns la concluzia că UML s-a dovedit că este un limbaj de
vizualizare şi design cu adevărat simplu şi accesibil, care, după un scurt training, poate efectua cu succes
diverse sarcini de proiectare. UML facilitează utilizarea acesteia pentru a determina cu uşurinţă şi fără
ambiguitate direcţia de lucru. Acest lucru este necesar în special atunci când lucrăm la un proiect de
specialişti din diferite domenii care lucrează cu diferite concepte. UML oferă un singur standard pentru
toţi, asigurându-se că, respectând standardul, chiar şi specialiştii din diferite domenii pot înţelege
structura şi comportamentul sistemului proiectat.

30
 Bibliografie

1. https://www.academia.edu/6702281/Diagrame_in_UML
2. https://ro.wikipedia.org/wiki/Unified_Modeling_Language;
3. http://inf.ucv.ro/~mihaiug/courses/poo/slides/Curs%2005%20-%20UML.pdf
4. https://www.uml-diagrams.org/use-case-diagrams.html
5. Help [Enterprise Architect]: aplicaţie
6. Conspectul de la obiectul AMOO

31