You are on page 1of 47

Ministerul Educaiei al Republicii Moldova

Universitatea Tehnic a Moldovei


Facultatea Calculatoare Informatic i Microelectronic
Catedra Automatic i Tehnologii Informaionale

PROIECT DE CURS
Disciplina: Analiza i modelarea sistemelor informaionale
Tema: Analiza i modelarea unui FTP server

A efectuat:

studenta grupei TI-111


Damaschin Elena

A verificat:

lector superior Nina Sava

Chiinu 2013

Cuprinsul
1.

Introducere ---------------------------------------------------------------------------------------------- 3

2.

Diagrama Use-Case ----------------------------------------------------------------------------------- 4

3.

Diagrama de interaciune (de secven i de colaborare) ------------------------------------- 7

4.

Diagrama claselor------------------------------------------------------------------------------------- 10

5.

Diagrama de stare ------------------------------------------------------------------------------------ 14

6.

Diagrama de activitate ------------------------------------------------------------------------------- 18

7.

Diagrama componentelor --------------------------------------------------------------------------- 22

8.

Diagrama de desfurare --------------------------------------------------------------------------- 24

9.

Modelarea Serverului FTP--------------------------------------------------------------------------26


9.1.

Diagrama Use-Case ---------------------------------------------------------------------------- 27

9.2.

Diagrama de interaciune (de Secven i de Colaborare) ----------------------------- 29

9.3.

Diagrama Claselor ------------------------------------------------------------------------------ 35

9.4.

Diagrama de stare ------------------------------------------------------------------------------ 37

9.5.

Diagrama de activiti ------------------------------------------------------------------------- 41

9.6.

Diagrama componentelor --------------------------------------------------------------------- 45

9.7.

Diagrama de amplasare -------------------------------------------------------------------------- 46

10.

Concluzie -------------------------------------------------------------------------------------------- 47

11.

Bibliografie ------------------------------------------------------------------------------------------ 47

1. Introducere
Este de mult tiut faptul c n trecut programatorii dezvoltau programe fr o bun analiz i o
bun proiectare a respectivelor programe. Faza de analiz i proiectare a unui proiect trebuie sa fie gata
nainte de realizarea codului, pentru a obtine o atenie mrit din partea diverilor dezvoltatori. Aceste
etape au fost ignorate n trecut, dar n prezent orice dezvoltator recunoate importana acestor faze
deoarece s-a dovedit ca de acestea depinde producerea si refolosirea de software. Pentru analiza si
proiectarea programelor s-au creat limbajele de modelare. Unul din aceste limbaje de modelare este
limbajul de modelare unificat - UML (The Unified Modeling Language).
UML nu este un simplu limbaj de modelare orientat pe obiecte, ci n prezent, este limbajul
universal standard pentru dezvoltatorii software din toata lumea. UML este succesorul propriu-zis al celor
mai bune trei limbaje de modelare anterioare orientate pe obiecte (Booch, OMT, and OOSE). Uml se
constituie din unirea acestor limbaje de modelare si n plus detine o expresivitate care ajut la rezolvarea
problemelor de modelare pe care vechile limbaje nu o aveau.
Limbajul de modelare modificat (UML - The Unified Modeling Language) ofera arhitecturi de
sisteme ce funcioneaz pe analiza si proiectarea obiectelor cu un limbaj corespunztor pentru
specificarea, vizualizarea, construirea si documentarea artefactelor sistemelor sofware si de asemenea
pentru modelarea n ntreprideri. UML este un limbaj de modelare care ofera o exprimare grafica a
structurii si comportamentului software. Pentru aceast exprimare grafic se utilizeaz notaiile UML.
Notaiile UML constituie un element esenial al limbajului pentru realizarea propriu-zisa a
modelrii i anume partea reprezentrii grafice pe care se bazeaza orice limbaj de modelare. Modelarea n
acest limbaj se realizeaz prin combinarea notaiilor UML n cadrul elementelor principale ale acestora
denumite diagrame. n cadrul UML-ului descoperim 9 tipuri de diagrame: diagrama cazurilor de utilizare,
diagrama de secventa, diagrama de colaborare, diagrama de clase (cea mai utilizata), diagrama de stari,
diagrama de componente, diagrama de constructie, diagrama de obiecte, diagrama de activitati. n cele ce
urmeaz vor fi prezentate notaiile UML care vor fi grupate dupa diagramele corespunztoare fiecarei
notaii n parte.

2. Diagrama Use-Case
Una dintre condiiile ce trebuie indeplinite ca un proiect sa aib succes este aceea ca cerinele
proiectului s fie definite ntr-o manier care s permit o uoar nelegere, indiferent de nivelul de
pregtire informatic al celui care este implicat n proiect. De asemenea, modificrile ce apar pe parcurs
n cerine trebuie s fie cu uurin asimilate de ctre membrii echipei de dezvoltare. Diagramele de
cazuri de utilizare au rolul de a reprezenta intr-o form grafic funcionalitile pe care trebuie sa le
indeplineasc sistemul informatic in faza sa final. De aceea modelul realizat de diagramele de cazuri de
utilizare alturi de documentele de descriere succinta a fiecrui caz de utilizare determinat poart numele
de model al cerinelor.
Diagramele de cazuri de utilizare sunt formate din dou categorii de entitai (actori si cazuri de
utilizare) si relaii intre acestea.
Actorii sunt roluri jucate de diverse persoane sau sisteme informatice i care interacioneaz cu
sistemul informatic aflat n dezvoltare. Este important de retinut faptul ca o persoan poate juca mai
multe roluri i un rol poate caracteriza mai multe persoane. Reprezentare grafic a actorilor in UML este
un omule stilizat avand la subsol un text ce reprezint rolul jucat de actor (figura 1).

Figura 1. Reprezentarea grafic a actorilor in UML


Determinarea actorilor se face rspunznd la ntrebrile:
-

cine este dorete sau interesat de informaiile aflate in sistem,

cine modific date,

cine se interacioneaz cu sistemul.

Raspunsurile concrete la cele patru intrebri de mai sus se introduc intr-o asa-numita tabel de
evenimente cu 4 coloane: Subiect(actor), Verb, Obiect, Frecven. Aceasta tabel de evenimente permite
de asemenea detectarea tuturor cazurilor de utilizare a sistemului.
Cazurile de utilizare reprezint secvene de tranzacii ce au loc n dialog cu sistemul i care sunt nrudite
din punct de vedere comportamental. Practic, un caz de utilizare modeleaza un dialog intre un actor si
sitemul informatic. Multimea de cazuri de utilizare a unui sistem reprezint toate modalitile in care
sistemul poate fi folosit.

Cazurile de utilizare :
-

sunt uniti de sine stttoare, bine delimitatate (nceputul i sfritul unui caz de utilizare sunt

cuprinse n acesta).

trebuie s fie iniiate de un actor i terminarea lor s fie 'vzut' de un actor


4

trebuie s ndeplineasc anumite scopuri de logic a problemei (dac nu se poate gsi un astfel de

obiectiv atunci cazul de utilizare trebuie regndit)


trebuie s lase sistemul ntr-o stare stabil (nu poate fi ndeplinit doar pe jumtate)

Cazurile de utilizare sunt orientate pe scop: reprezint ceea ce sistemul trebuie s fac i nu cum. Ele sunt
neutre din punct de vedere tehnologic, potand fi utilizate n orice proces sau arhitectur de aplicaie.
Reprezentarea grafic a cazurilor de utilizare in UML se realizeaz prin intermediul unui oval avand la
baz numele cazului de utilizare (figura 2).

Figura 2. Reprezentarea grafica a cazurilor de utilizare in UML


Fiecare caz de utilizare ce apare in una din diagramele ce modeleaza functionalitatea sistemului
informatic trebuie sa fie insotite de un document de descriere a sa ce va respecta urmatorul sablon:
Nume
Descriere
Autori
Stare
Prioritate
Precondiii
Postcondiii
Calea principal (sau BCE - Basic Course of Events)
Ci alternative (sau ACE - Alternate Course of Events)
Ci de excepie
Relatii ntre actori i cazuri de utilizare:
- relatia de asociere (comunicare) (figura 3) - directia de navigare a relatiei (sageata) sugereaza
cine initiaza comunicarea. In general comunicare intre actor si caz de utilizare este bi-directionala

Figura 3. Reprezentarea grafica relatiei de comunicare intre


actori si cazuri de utilizare
Relaii ntre cazuri de utilizare (figura 4):
- relatia de utilizare: are loc intre un caz de utilizare si oricare alt caz de utilizare ce utilizeaz
funcionalitatea acestuia. Se reprezint grafic printr-o linie avnd la captul corespunzator cazului de
utilizare folosit un triunghi si este etichetat cu stereotipul <<Uses>> (stereotipul este un concept introdus
in UML care permite extinderea elementelor de modelare de baza pentru a creea noii elemente).
5

- relatia de extindere: este folosita pentru a sugera un comportament optional, un comportament care
are loc doar in anumite conditii sau fluxuri diferite ce pot fi selectate pe baza selectiei unui actor.
Reprezentarea grafica este similara cu cea a relatiei de utilizare, dar eticheta este <<Extends>>.

Figura 4. Reprezentarea grafica a relatiilor de extindere si utilizare


intre cazuri de utilizare
Relaii ntre actori (figura 5):
- relaia de generalizare: semnific faptul ca un actor poate interaciona cu sistemul in toate
modalitile prin care interacioneaz un altul. Se reprezint ca o relaie de extindere intre dou cazuri de
utilizare far a avea stereotip.
- relatia de dependen: semnific faptul c, pentru a interaciona cu sistemul informatic prin
intermediul unui caz de utilizare, un actor depinde de alt actor. Se reprezint printr-o linie frnta avnd la
un capt o sageat.

Figura 5. Reprezentarea grafica a relatiilor de generalizare si dependenta


intre actori
Observatie: Exista o serie de cazuri de utilizare asa-zis 'ascunse' care nu sunt identificate intotdeauna in
fazele analizei functionale (in special din cauza faptului ca interlocutorii nu sunt familiarizati cu
informatica): securitate, arhivare, infrastructura arhitectural, verificare. Se recomanda introducerea
acestor cazuri de utilizarea in toate modelele de cerinte.

3. Diagrama de interaciune (de secven i de colaborare)


Diagrama de cazuri de utilizare reprezint imaginea sistemului privit din exterior. Funcionalitatea unui
caz de utilizare este dat de un flux de evenimente (specificat n documentul de descriere al cazului de
utilizare).
Un scenariu reprezint o cale (un drum) prin fluxul de evenimente al unui caz de utilizare. Scenariile pot
fi privite ca instane (sau realizri) ale cazurilor de utilizare: ele descriu o secven de aciuni concrete
care pot avea loc la un moment dat n sistem.Determinarea scenariilor are rolul de a ajuta:
- nelegerea funcionalitii cazurilor de utilizare,
- specificarea modului n care responsabilitile unui caz de utilizare sunt distribuite obiectelor
i claselor din sistem,
- identificarea obiectelor i claselor,
- identificarea interaciunilor ntre obiecte, necesare pentru realizarea unei pri funcionale
concrete descris de un caz de utilizare.
- comunicarea pe baza specificaiilor proiectului
Fiecare caz de utilizare este o reea de scenarii coninnd un scenariu principal i mai multe scenarii
secundare. Iniial se definesc scenariile primare pentru toate cazurile de utilizare. Scenariile alternative
(secundare) se definesc pn n momentul n care se observ c fiecare nou scenariu repet o serie de pai
identificai n scenariile precedente (de obicei, acest fapt are loc dupa modelarea a 80% din scenariile
secundare identificate).
Dac fluxul de eveniment al unui caz de utilizare este descris prin intermediul unui text (documentul de
descriere al cazurilor de utilizare), scenariile se descriu prin intermediul aa-numitelor diagrame de
interaciune. n UML avem dou tipuri de diagrame de interaciune: diagramele de secven i de
colaborare. Fiecare dintre aceste diagrame reprezint o vedere grafic diferit a unui scenariu.
Diagrame de secven
Diagramele de secven prezint interaciunile care au loc ntre diverse obiecte ale unui sistem, ordonate
cronologic. Ele determin obiectele i clasele implicate ntr-un scenariu i secvenele de mesaje transmise
ntre obiecte necesare ndeplinirii funcionalitii scenariului. Diagramele de secven sunt asociate unui
caz de utilizare.
Reprezentarea grafic a obiectelor n diagrama de secven se realizeaz ca n figura 7, Curs 2. Prezena
numelui obiectului sau al clasei este opional, ns nu pot lipsi ambele n acelai timp. Atunci cnd
numele obiectului lipsete, reprezentarea grafic simbolizeaz un obiect anonim (utilizat n reprezentarea
opricrui obiect al unei clase).

Fiecrui obiect i corespunde o linie a timpului, reprezentat printr-o linie punctat sub reprezentarea
obiectului. Mesajele transmise ntre obiecte sunt reprezentate prin sgei (de la obiectul client, surs spre
obiectul server, destinaie, receptor) etichetate cu numele mesajului (figura 1).

Figura 6.
n cadrul unei diagrame de secven pot fi implicai i actori (figura 8).

Figura 7.
Figura 8 prezint scenariul de adugare a unui nou curs opional n sistem (unde CursuriDlg
este clas de interfa, CursuriCtl este clas de control, iar CursOptional este clas entitate).

Figura 8.
8

n fazele timpurii ale analizei, diagramele de secven sunt utilizate i la specificarea


funcionalitii claselor de interfa, fr a sugera modul de implementare a acestora.
Observaii:
'Ct de complexe trebuie s fie diagramele de secven?' Diagramele de secven trebuie s fie cat mai
simple (abordarea KISS Keep It Simple and Stupid) - ele sugereaza ce mesaje sunt transmise intre
obiecte si nu cum se realizeaza in detaliu o anumita functionalitate.
'Cum se modeleaz scenariile ce conin logic condiional?' n cazul n care logica este simpl, se
construiete o diagram de secven simpl, cu puine mesaje, la care se adaug comentarii de descriere a
condiiilor de parcurgere (in figura 3 se poate adauga un mesaj suplimentar transmis de un obiect al clasei
CursuriCtl

pentru

semnala

eroare

la

verificarea

datelor

introduse

).

Dac logica condiional implic un set numeros de mesaje, atunci se va realiza cte o diagram de
secven pentru fiecare dintre cele trei componente ale logicii (una pentru if, una pentru then i o a treia
pentru else).
Diagrame de colaborare
Diagramele de colaborare prezint interaciunile dintre obiecte organizate relativ la acestea i a legturilor
dintre ele. Diagramele de colaborare conin (figura 10):
-

obiecte, n reprezentarea lor grafic sub form de dreptunghiuri

legturi ntre obiecte, reprezentate grafic prin linii de conectare

mesaje, reprezentate ca etichete ale legturilor, i care conin o sgeat ndreptat spre

obiectul server (receptor al mesajului).

Figura 9
Folosind instrumentul RationalRose se pot genera diagramele de colaborare din diagrame de
secven (meniu Browse, comanda Create Collaboration Diagram) sau invers (meniu Browse,
comanda Create Sequence Diagram).
9

4. Diagrama claselor
Diagramele de clase fac parte din categoria diagramelor statice. Ele descriu structura intern a sistemului
informatic prin identificarea claselor, a atributelor i operaiilor acestora i a relaiilor dintre clase.
Construcia diagramelor de clase are loc n faza de elaborare a sistemului informatic fiind cele mai
importante din aceasta faza.
Selectarea claselor necesit anumite deprinderi.

O abordare metodic a determinrii claselor ce

modeleaz soluia unei probleme informatice este aceea de a extrage substantivele eseniale din
documentul de specificaie. O metod mult mai rapid este accea de a extrage toate substantivele care
apar n diagrama de cazuri de utilizare (att n denumirile actorilor ct i a cazurilor de utilizare). Dup
dobndirea unei anumite experiene n domeniu, n acest proces de selectare a substantivelor intervine i o
filtrare a acelor substantive care nu vor reprezenta clase bune (multe dintre acestea reprezint de fapt
atribute ale unor alte clase din domeniul problemei) ex. cont bancar.
Odat completat lista iniial de substantive se vor aplica o serie de 7 reguli de filtrare. Se vor elimina
toate clasele-candidat care au una dintre urmtoarele caracteristici:
1.

Este redundant: dou substantive care reprezint acelasi lucru sunt redundante (ex. main

automobil)
2.

Este irelevant: substantivul nu este relevant pentru sistemul modelat (clasa 'Loc' nu este

relevanta pentru un sistem de rezervare de bilete de avion, insa poate fi relevanta pentru un sistem
informatic de proiectare a avioanelor)
3.

Este atribut: substantivul reprezinta mai degraba un atribut al unei clase decat o clasa in

sine (ex. cont bancar)


4.

Este operatie: substantivul exprima un calcul sau proces care trebuie realizat (ex. calcul

discount)
5.

Este rol: substantiv exprima o stare a unui obiect (ex. masina buna)

6.

Este eveniment: (ex. listarea trebuia facuta o data pe spatamana - saptamana nu reprezinta

un nume de clase)
7.

Este construcie de implementare: denumeste un dispozitiv fizic imobil utilizat de sistem

(ex. imprimanta). In aplicatiile in timp-real se utilizeaza modelarea prin clase a acestor dispozitive, proces
care poarta numele de reificare.
Objectory introduce 3 tipuri de clase (marcate n UML ca stereotipuri) - figura 3:
- Claseentiti (sau clase domeniu) reprezint nucleul unei aplicaii, rein informaii legate de entittile
persistente i captureaz serviciile ce conduc majoritatea interaciunilor n aplicaie. De obicei clasele
entitate trebuie s:
nmagazineze i redea valori de atribute,
creeze i sa tearga entiti,
furnizeze un comportament dependent de modificarea starii entitatii.
10

-Clase de interfa reprezinta grania dintre actorii care doresc s interacioneze cu aplicaia i clasele
entitate. Majoritatea sunt componente ale interfeei utilizator (fiecare cutie de dialog este o clas de
interfa), modeleaza comunicarea cu alte aplicaii sau reprezinta clase wrapper peste anumite
componente soft. Se determina studiind:
modul in care doresc actorii s ceeaze entiti,
interfaa ntre aplicaie i alte sisteme,
modalitatea de vizualizare a informaiilor (rapoarte).
-Clase de control (controller) coordoneaz activitatea n interiorul aplicaiei. Se creaz cte o clas
controller pentru fiecare caz de utilizare. Pot juca unul din urmtoarele roluri:
modelarea unui comportament tranzacional,
secven de control specific unuia sau mai multor cazuri de utilizare,
serviciu ce separ obiectele entitate de obiectele de interfa.

Figura 10. Reprezentarea grafica in UML a tipurilor de clase


Relaii ntre clase - asigur posibilitatea colaborrii ntre obiectele unui sistem informatic. In UML se pot
modela trei tipuri de relatii intre clase:
-asociere - modul n care obiectele unei clase sunt conectate cu obiectele altei clase. Asocierile pot fi
extrase din cazurile de utilizare sau din tabela de evenimente ('Clientul plaseaz Comenzi', 'Documentul
conine Cuprins'). Reprezentarea grafic (figura 10) este o linie (sau segmente de dreapta) care uneste
clasele asociate avand, optional, o eticheta care sugereaza natura relatiei dintre acestea. Atunci cand
asocierea nu este bidirectionala, capetele liniei contin o sageata. Multiplicitatea se poate specifica la
ambele capete ale unei asocieri si poate avea valori concrete (1,4), intervale de valori (0..5) sau poate fi
nedefinita (*).

In cazul in care nu se specifica, multiplicitatea este considerata implicit 1.


11

agregare - modeleaza o relatie de tip 'parte/intreg' in care obiectul/obiectele parte pot face parte din mai
multi intregi (in momente de timp diferite). In reprezentarea grafica se adauga un romb gol la capatul
corespunzator clasei 'intreg'.
compunere - modeleaza o relatie de tip 'parte/intreg' in care obiectul/obiectele parte compun un singur
intreg pe toata perioada ciclului de viata si se distrug in momentul distrugerii intregului. In reprezentarea
grafica se adauga un romb plin la capatul corespunzator clasei 'intreg'.
legtur (clas asociere) - reprezinta o colectie de atribute care caracterizeaza o asociere. Clasele
asociere apar atunci cand nu exista un mod logic de a plasa aceste atribute la nivelul unei clase aflate in
sistem.
asociere reflexiv - asociere intre obiecte ale aceleasi clase.

Figura 11. Reprezentarea grafica a relatiilor de tip asociere in UML


-generalizare - modeleaza mostenirea proprietailor, operaiilor si relatiilor ntre dou clase (rafinarea,
specializare a clasei). Clasa generala poarta numele de superclas, iar clasa specializata de numeste
subclas. Generalizarea apare atunci cnd orice exemplu de obiect al unei clase este un exemplu valid de
obiect al altei clase.

Figura 12. Reprezentarea grafica a relatiei de generalizare/specializare in UML


12

-dependen - este utilizata atunci cand modificarea unei clase are impact asupra comportamentului/starii
altei clase (de obicei atunci cnd o clas utilizeaz o alt clas ca argument pentru una din operaiile sale).

Figura 13. Reprezentarea grafica a relatiei de dependenta in UML

Reprezentarea si descrierea relatiilor in diagrama claselor


Element

Descriere

Clas

O clas este reprezentat printr-un dreptunghi cu trei


compartimente: n cel de sus se trece numele clasei, n mijloc se
trec atributele clasei iar jos se trec operaiile specifice clasei.

Motenire

Motenirea este o relaie care indic faptul c o clas


motenete caracteristicile unei clase printe. Sensul sgeii
indic sensul n care se poate spune despre clasa copil c este
o<-i>, sau este de tipul<-i> clas printe.

Asociere

Asocierea este o relaie generic ntre dou clase. Aceste relaii


pot fi de tipurile pot defini i regulile numerice de asociere (unu
la unu, unu la mai muli, mai muli la mai muli).

Dependen

Atunci cnd o clas depinde de o alt clas, n sensul c utilizeaz


acea clas ca i atribut al su, se folosete relaia de dependen.

Agregare

Agregarea indic o relaie de tip ntreg-parte (se poate spune


despre clasa printe c are clase de tip copil). n aceast relaie,
clasa copil poate exista i fr clasa printe.

Compoziie

Aceast relaie deriv din agregare dar se utilizeaz atunci cnd o


clas copil nu poate exista dect n cazul existenei clasei printe.

Anexa 1
Notaie

13

5. Diagrama de stare
Cazurile de utilizare i scenariile reprezint modaliti de descriere a comportamentului sistemelor
informatice (vzut ca interaciuni ntre obiecte).
comportamentului n interiorul unui obiect.

n anumite cazuri ns este necesar studierea

UML furnizeaz diagramele de tranziie a strilor i

diagramele de activiti pentru modelarea comportamentului obiectelor.


n UML diagramele de tranzitie a strilor sunt utilizate n descrierea comportamentului obiectelor
aparinnd unui clase.
O stare (concret) este caracterizat de valorile proprietilor unui obiect i de mulimea mesajelor care
pot fi acceptate de ctre acest obiect la un moment dat. O stare conine descrierea unui invariant de stare
(condiie logic adevrat pentru toate obiectele care se afl n starea respectiv), i a trei proceduri
speciale: entry, exit i do. Aceste proceduri descriu secvenele de aciuni care vor fi executate n
momentul n care un obiect intr (entry), prsete (exit) sau se afl (do) n starea respectiv. O stare se
reprezint grafic prin intermediul unui dreptunghi cu colurile rotunjite, afind n partea superioar un
nume de stare. n partea inferioar a dreptunghiului opional poate exista un compartiment care conine
expresiile ce definesc invariantul de stare i cele trei proceduri speciale.
O tranziie exprim o situaie n care un obiect poate trece dintr-o stare n alta. Tranziiile se reprezint
grafic prin intermediul unor arce de cerc, linii simple sau linii poligonale orientate i (opional) etichetate
care unesc dou stri, numite stare surs, respectiv destinaie. Eticheta unei tranziii este format dintr-o
signatur de mesaj, o condiie (expresie logic) i o secven de activiti care au loc n momentul
declanarii tranziie. Pentru un obiect oarecare o tranziie este declanat atunci cnd obiectul se afl n
starea surs a acesteia, execut operaia corespunztoare mesajului i este ndeplinit condiia specificat
n etichet.
Hrile de stri permit reprezentarea ierarhic a strilor unui obiect prin intermediul strilor compuse
(ntlnite i sub denumirea de XOR-stri, stri abstracte sau super-stri). Strile compuse conin un
numr finit de stri simple sau compuse. Un obiect aflat ntr-o stare compus se va afla n una i numai
una din sub-strile acesteia. Strile compuse se reprezint grafic la fel ca strile simple, la care se adaug
un compartiment special, localizat ntre numele strii i compartimentul destinat afirii invarianilor de
stare i a procedurilor speciale. n cadrul acestui compartiment sunt reprezentate grafic toate sub-strile
corespunztoare.

14

Figura 14. Etichetarea tranziiilor n hrile de stri UML


Hrile de stri permit modelarea de comportamente paralele ale unui obiect prin intermediul strilor
ortogonale (denumite i AND-stri sau stri concurente). Strile ortogonale sunt formate din mai multe
componente ortogonale, fiecare dintre acestea coninnd diverse sub-stri. Un obiect aflat ntr-o stare
ortogonal se va afla de fapt n cte o stare corespunztoare fiecrei componente ortogonale a acesteia.
Reprezentarea grafic a strilor ortogonale este asemntoare reprezentrii strilor compuse,
componentele ortogonale ale acestora fiind delimitate prin linii punctate verticale.

Figura 15. Principalele notaii ale hrilor de stri UML


De asemenea, hrile de stri introduc o serie de stri speciale, numite pseudo-stri. Pseudo-strile sunt
stri intermediare care permit conectarea mai multor tranziii n scopul descrierii unor situaii complexe
de modificare a strii concrete a unui obiect. Cele mai importante pseudo-stri definite n UML sunt:
-

starea iniial - indic sub-starea implicit n care intr un obiect n cazul declanrii unei

tranziii a crei stare destinaie este o stare compus. Se reprezint grafic sub forma unui cerc plin.

15

starea final - indic prsirea contextului unei stri compuse. n cazul n care starea final

aparine strii compuse de la cel mai nalt nivel al ierarhiei de stri (este rdcina ierarhiei de stri)
intrarea o tranziie spre aceast stare semnific distrugerea obiectului.
-

starea istoric - este utilizat atunci cnd sub-starea iniial a unei stri compuse nu este

fixat dect pentru prima tranziie spre aceast stare compus, ea fiind dat mai apoi de ultima sub-stare
activ. n figura 16 o prim tranziie spre starea Pornita implic activarea sub-strii Normal, urmtoarele
tranziii activnd sub-starea (Normal sau Marsarier) activ n momentul ultimei prsiri a strii Pornita.
Pseudostrile istoric au dou variante: superficiale i profunde - pseudostrile istoric profunde activeaz
recursiv ultima substare activat a ultimei stri compuse active.
Alturi de pseudostrile de ieire, de intrare i istoric, UML mai introduce alte trei pseudostri fr
semnificaie semantic, avnd ca rol creterea lizibilitaii diagramei:
- strile ramificaie (branch - pentru reprezentarea a dou sau mai multe tranziii dintr-o stare surs
comun,

declanate

de

acelai

eveniment,

dar

cu

grzi

diferite),

- fork i join (pentru tranziii n i din stri aflate n componente ortogonale) - figura 3.

Figura 16. Pseudostrile ramificaie (a), fork (b) i join (c)


O data cu introducerea starilor compuse se introduce si noiunea de tranziie de completare (sau
terminare). O astfel de tranziie este neetichetat cu un nume de eveniment (eventual ea poate avea
asociata o conditie). Dac n urma tratrii unui anumit eveniment un obiect se afl ntr-o configuraie de
stri ce permite declanarea de tranziii de terminare atunci spunem c obiectul respectiv a atins o
configuraie instabil.

16

Figura 17. Exemplu de utilizare a unei tranziii de terminare


Tratarea urmtorului eveniment se va realiza n acest caz doar dup efectuarea unui numr corespunztor
de pai, pn cnd se atinge o configuraie stabil (n exemplul din figura 4 obiectul va atinge o
configuraie instabil imediat dup tratarea evenimentului e; n aceast faz se realizeaz un nou pas de
trecere a obiectului n starea C). n cazul unei proiectri incorecte se poate ajunge n situaia n care nu se
atinge niciodat o configuraie stabil.

Figura 18. Activarea strilor n cazul unei tranziii (e1) n cadrul unei stri compuse (B)
a) intrare implicit C va fi starea activ,
b) intrare explicit stare activ
c) intrare prin istoric dac se intr pentru prima dat n B de la crearea obiectului
starea activ va fi C, altfel stare activ este ultima sub-stare activ a strii B (C sau D)

17

6. Diagrama de activitate
Modelarea activitatilor reprezinta un tip particular de modelare comportamentala tratand activitatile si
responsabilitatile elementelor dintr-un sistem informatic.
Diagramele de activitati se folosesc atunci cand celelalte diagrame utilizate in modelarea
comportamentala nu sunt suficient de expresive. Se recomanda utilizarea diagramelor de activitati in
oricare din urmatoarele situatii:
Operatii de nivel inalt: Atunci cand o clasa contine operatii complexe ce presupun mai multi pasi pentru
a fi realizate, diagramele de activitati sunt utile pentru a prezenta acei pasi sub forma unei secvente de
activitati.
Fluxuri de procese: Diagramele de activitati sunt potrivite nu doar la modelarea operatiilor software ci si
in modelarea proceselor de business. Prin intermediul acestora se specifica cine realizeaza anumite
activitati, care sunt deciziile ce trebuiesc luate si ce documente sunt generate in cadrul procesului.
Sintetizarea mai multor diagrame de secventa: Atunci cand pentru un caz de utilizare se dezvolta mai
multe diagrame de secventa acestea pot fi sintetizate printr-o diagrama de activitati . Comportamentul
complex al cazului de utilizare poate fi inteles cu mai multa usurinta daca se defineste si o diagrama de
activitati.
Elementecele mai importatate ale unei diagrame de activitati sunt Activitatile, Fluxurile de control si
Fluxurile obiect:
Activitatea reprezinta procesul prin care un element al sistemului informatic isi indeplineste
responsabilitatile pe care le are. Fiecare astfel de element are responsabilitatea de a reactiona la stimuli
externi, la mesajele receptionate, si aceste responsabilitati pot fi descrise prin intermediul activitatilor.
O activitate poate fi detaliata in actiuni. Aceste actiuni pot fi executate in trei cazuri distincte:
- la intrarea intr-o activitate (aceste actiuni sunt precedate de cuvantul "entry")
-

la

iesirea

dintr-o

activitate

(actiuni

precedate

de

cuvantul

"exit")

- dupa intrarea intr-o activitate si care continua pana cand activitatea se termina (actiuni marcate
prin cuvantul "do").
Activitatile se reprezinta grafic prin intermediul unui dreptunghi rotunjit, avand in centru
denumirea acestora (figura 1).

Figura 19. Reprezentarea grafica a activitatilor

18

Fluxurile de control indica ordinea in care se realizeaza activitatile. Un flux de control este reprezentat
printr-o sageata ce leaga doua activitati (numite activitate sursa si activitate destinatie) si semnifica
inceperea realizarii activitatii destinatie imediat dupa finalizarea activitatii sursa. Fluxurile de control mai
poarta numele de tranzitii implicite sau automate deoarece nu sunt etichetate si sunt "activate" imediat
dupa terminarea activitatii sursa.

Figura 20. Fluxuri de control


Similar cu diagramele de tranzitie a starilor, si in cazul diagramelor de activitati exista psedo-activitati
initiale si finale cu reprezentarea grafica si semnificatia cunoscuta. O diagrama de activitati are o singura
stare initiala si poate avea mai multe stari actiune finale.
Fluxurile-obiect indica faptul ca o actiune are nevoie de un anumit obiect ca data de intrare sau
returneaza un obiect in urma executiei sale. Fluxurile obiect sunt reprezentate grafic prin intermediul unor
linii punctate orientate si care uneste o activitate si un obiect. Figura urmatoare prezinta obiectele utilizate
de activitatile asociate unei aplicatii contabile.

Figura 21. Fluxuri-obiect


19

Analizand numele de activitati din figura 20 se observa ca acestea contin informatii legate de natura
intrarilor si iesirilor fiecarei activitati. In figura 21 intrarile si iesirile sunt prezentate explicit prin
intemediul obiectelor, deci nu mai este necesara introducerea redundata a acestora in denumirile
activitatilor. Unul dintre avantaje este acela ca numele activitatii poate sa exprime mai direct natura
actiunilor ce se efectueaza, iar fluxurile-obiect indica clar intrarile si iesirile din/in activitati.
Atunci cand un flux-obiect indica ordinea de realizare a activitatilor dintr-o diagrama, prezenta
unui flux de control nu mai este necesara. Acest lucru se intampla atunci cand un flux-obiect contine un
obiect produs de o activitte si care este utilizat in activitatea executata imediat dupa aceasta.
Pentru a reprezenta cat mai exact elementele care sunt responsabile de executarea unor activitati,
in UML sunt folosite asa- numitele culoare (in orig. swimlane). Un culoar este o regiune (banda)
verticala ca indica elementul care are responsabilitatea de a executa activitatile localizate in aceasta
regiune. De exemplu, aplicatia contabila poate avea urmatoarele culoare (ilustrate in figura 22):
Contabil: prezinta activitatile aflate in responsabilitatea unui contabil. Culoarul releva ca
introducerea datelor cade in responsabilitatea contabilului.
De aceea activitatea Contabilul Introduce Date se transforma intr-o varianta mai scurta: Introducere
Date.
Sistemul contabil: contine activitatile de care este responsabila aplicatia, si anume generarea datelor
Imprimanta: contine activitatile ce cad in responsabilitatea imprimantei.
De notat, ca observatie, faptul ca prezenta culoarelor permit redenumirea activitatilor prin
omiterea numelor elementelor responsabile.

Figura 22. Culoare in diagramele de activitati


In UML, un culoar este reprezentat ca o banda verticala, delimitat de culoarele vecine prin linii
verticale. Banda este etichetata cu elementul responsabil pentru realizarea activitatilor incluse in bada
verticala corespunzatoare.

20

O decizie presupune selectarea, pe baza unei anumite conditii, a unui flux de control dintr-un set de mai
multe fluxuri de control . De exemplu, odata ce un raport este listat de catre contabil, alte rapoarte pot fi
selectat si listate daca cotabilul alege (ia decizia!) sa faca acest lucru.
In UML o decizie este reprezentata grafic ca un romb cu un set de fluxuri de control care intra si un set de
fluxuri de control ce ies din acesta. Fiecare dintre fluxurile de control ce paraseste rombul este etichetat
cu o conditie, afisata intre doua paranteze patrate, care trebuie sa fie satifacute pentru ca tranzitia spre o
activitate reprezentata de fluxul de control sa aiba loc.
In figura 5, deoarece rombul para in culoarul "Contabil" rezulta ca intra in responsabilitatea
contabilului sa ia decizia daca se mai pregateste un raport pentru listare sau nu.

Figura 23. Utilizarea deciziei


Notiunea de concurenta in diagrama de activitati presupune selectarea mai multor fluxuri simultan. De
exemplu, in timp ce listeaza un raport, imprimanta trebuie sa monitorizeze aparitia alto cereri de listare.
In UML concurenta este reprezentata printr-o scurta bara, verticala sau orizontala. Daca intr-o astfel de
bara intra un singur flux de control si ies doua sau mai multe fluxuri de control, ea indica declansarea
tuturor tranzitiilor ce ies odata ce tranzitia corespunzatoare fluxului de control care intra are loc. Acest
lucru poarta numele de ramificare a controlului.
In mod similar, daca intr-o bara reprezentand concurenta intra mai multe fluxuri de control si iese un
singur flux , tanzitia corespunzatoare fluxului de control care iese are loc daca toate fluxurile de control
care intra au fost deja declansate. O astfel de situatie poarta numele de sincronizare a controlului. Figura
de mai jos arata ca imprimanta utilizeaza concurenta pentru a lista un raport utilizand activitatea Listeaza
Informatia si pentru a monitoriza alte cereri de listare in timpul tratarii cererii curente, prin intermediul

21

activitatii Monitorizarea Cererilor de Listare. Odata ce ambele activitati s-au terminat, un contabil poate
alege listarea unor alte rapoarte.

Figura 24. Concurenta in diagrame de activitati

7. Diagrama componentelor
O diagram de componente prezint dependenele existente ntre diverse componente software (cod surs,
cod binar, executabile, librarii cu legare dinamica etc) ce compun un sistem informatic. Aceste
dependente sunt statice (au loc in etapele de compilare sau link-editare) sau dinamice (au loc in timpul
executiei).
O componenta este un modul soft (cod sursa, cod binar, dll, executabil etc) cu o interfata bine definita.
Un tip de component reprezint o parte distinct, realocabil, a implementrii unui sistem. Instana unei
componente este o unitatea de implementare n execuie i poate fi utilizat pentru reprezentarea unitilor
de implementare care au o identitate n momentul execuiei.
Reprezentarea grafic a componentelor n UML este dat n figura 3. Un tip de component are asociat
un nume, iar o instan a unei componente are asociate (opional) un nume i un tip. In general numele
unei componente este numele fisierului reprezentat de componenta. Obiectele implementate de o instan
de component se reprezint grafic n interiorul simbolului instanei de component. n mod analog se
reprezint grafic clasele implementate n componente.

Figura 25. Reprezentarea grafica a componentelor in UML


22

Diagrama de componente este un graf de componente ntre care exist relaii de dependen sau de
compunere (componente incluse fizic n alte componente).
Dependentele intre componente se reprezinta grafic prin linii ntrerupte ntre o component
client i o component furnizor de servicii, orientate spre componenta furnizor. Relatia de dependeta
semnifica faptul ca clasele incluse in componenta client pot mosteni, instantia sau utiliza clase incluse in
componenta furnizor (sau server).
O diagram care conine tipuri de componente poate fi utilizat, spre exemplu, pentru
reprezentarea de dependene statice, cum este dependena de compilare ntre diverse programe .

Figura 26. Dependente statice si doua reprezentari grafice alternative


a componentelor in Rational Rose
De asemenea, pot exista relatii de dependenta intre componente si interfete ale altor componente, relatii
care semnifica faptul ca clientul utilizeaza operatii ale componentei server.

Figura 27. Dependente dinamice intre componentele unui sistem informatic


de gestiune a biletelor de calatorie cu avionul
Instrumentul Rational Rose introduce o serie de stereotipuri predefinite pentru componente:
- programe principale (<<Main Program>>)

- librarii cu legare dinamica (<<DLL>>)

- subprograme (<<SubProgram>>)

- procese ( <<Task>> )

- pachete (<<Package>>)

- executabile ( <<EXE>>)
23

8. Diagrama de desfurare
Diagramele de desfurare prezint configuraia elementelor de procesare din timpul execuiei i
componentele, procesele i obiectele care le conin. Fiecare model al unui sistem informatic are asociata
o singura diagrama de exploatare. Instanele componentelor soft reprezint manifestri a unor uniti de
cod n cadrul execuiei. Componentele care nu exist ca entiti de execuie nu apar n aceste diagrame, ci
doar n diagramele de componente.
O diagram de desfurare este un graf de noduri conectate prin asocieri de comunicare. Nodurile pot
conine instane ale componentelor (componenta exist sau se execut pe nodul respectiv). Componentele
pot conine obiecte (acestea sunt localizate n componente).

Componentele sunt conectate cu alte

componente sau interfeele acestora prin intermediul unor relaii de dependen (sgei ntrerupte) ceea ce
reprezint faptul c o component folosete serviciile altei componente. Pot fi utilizate stereotipuri pentru
a preciza n detaliu tipul dependenei dintre componente.
Un nod este o entitate fizic ce reprezint o resurs de procesare, avnd o memorie i anumite capabiliti
de procesare (dispozitive de calcul, resurse umane, resurse de procesare mecanic).
Un nod este reprezentat grafic prin intemediul unui paralelipiped. Un tip de nod are asociat un nume, iar o
instan a unui nod are asociate (opional) un nume de instan i un nume de tip (nume instan : nume
tip). O asociere ntre dou noduri indic existena unei ci de comunicare ntre noduri. Asocierea poate
avea un stereotip care s indice tipul de comunicare (tipul de canal, reea).
Diagramele de desfurare pot fi utilizate pentru reprezentarea componentelor ce pot aparine anumitor
noduri. Aceast relaie se reprezint grafic prin intermediul unei linii ntrerupte ntre un nod i o
component, avnd stereotipul <<support>> sau prin ncuibrirea grafic a simbolului componentei n
cadrul simbolului ce reprezint nodul (figura 6).

Figura 28. Diagrama de desfurare pentru o aplicatie


de gestiune a biletelor de calatorie cu avionul

Migrarea instanelor de componente dintr-un nod n altul, sau migrarea obiectelor de la o component la
alta poate fi implementat grafic utiliznd stereotipul <<become>> ataat relaiei de dependen. n
aceast situaie instana componentei/obiectul vor aparine unei instane a unui nod/unei instane de
component doar o perioad de timp din ciclul lor de via.
Instrumentul Rational Rose contine un editor de diagrame de desfurare particulare. Aceste diagrame de
desfurare contin noduri de doua tipuri: procesoare si dispozitive. Intre aceste noduri se pot trasa relatii
de conexiune.
Procesoarele reprezinta componente hard capabile sa execute programe. La nivelul fiecarui procesor pot
fi identificate procese si modul de planificare al acestora (preemptiv, non-preemptiv, ciclic, prin
intermediul unui algoritm particular sau manual) - figura 7.
In aceste diagrame, procesele reprezint fire de excutiedistince (ex. programul principal, sau obiecte
active).

Figura 29. Reprezentarea grafica a procesoarelor in Rational Rose


Dispozitivele reprezinta componente hard fara putere de calcul. Numele asociat unui
dispozitiv este in general unul generic (ex. imprimanta, modem, terminal etc) - figura 8.
O conexiune reprezinta o legatura hard (in general bidirectionala) intre doua dispozitive sau
procesoare.

Figura 30. Diagrama de desfurare a unui sistem informatic oarecare

25

9. Modelarea Serverului FTP.


File Transfer Protocol ( FTP ) este un protocol standard de reea utilizat pentru a transfera fiiere de la o
gazd la o alt gazd printr-o reea bazat pe TCP , cum ar fi Internetul .
FTP este construit pe o arhitectura client -server i utilizeaz conexiuni de control i de date separate,
ntre client i server . [ 1 ] utilizatori FTP se pot autentifica folosind un clar - text de sign- in de protocol ,
n mod normal , sub forma unui nume de utilizator i o parol , dar se poate conecta anonim dac serverul
este configurat pentru a permite acest lucru . Pentru transmiterea securizat care ascunde ( cripteaz ),
numele de utilizator i parola, apoi cripteaz coninutul , FTP este adesea securizat cu SSL / TLS ( "
FTPS " ) . SSH File Transfer Protocol ( " SFTP " ) este uneori folosit n loc , dar este diferit de vedere
tehnologic .
Primele aplicaii client FTP au fost cereri de linie de comand dezvoltate nainte de sistemul de operare a
unei interfee grafice , i sunt nc livrate cu majoritatea sistemelor de operare Windows , Unix , si Linux .
[ 2 ] [ 3 ] Zeci de clienti FTP si utilitati de automatizare de atunci au fost dezvoltat pentru desktop-uri ,
servere , dispozitive mobile , i hardware-ul , i FTP a fost ncorporat n sute de aplicaii de
productivitate , cum ar fi editori de pagini web .
Istoria aparitiei a fost elaborarea caietului de sarcini iniial pentru File Transfer Protocol a fost scris de
Abhay Bhushan i publicat ca RFC 114 la 16 aprilie 1971. Pn n 1980, a fugit pe FTP NCP,
predecesorul de TCP / IP. [2] Protocolul a fost ulterior nlocuit cu o versiune TCP / IP, RFC 765 (iunie
1980) i RFC 959 (octombrie 1985), caietul de sarcini actual. Mai multe standarde propuse modifica RFC
959, de exemplu, RFC 2228 (iunie 1997) propune extensii de securitate i RFC 2428 (septembrie 1998),
adaug suport pentru IPv6 i definete un nou tip de modul pasiv.
FTP poate rula n mod activ sau pasiv , care determin modul n care se stabilete conexiunea de date.[5]
n modul activ , clientul creeaz o conexiune de control TCP . n situaiile n care clientul este in spatele
unui firewall i n imposibilitatea de a accepta conexiuni TCP de intrare , modul pasiv poate fi folosit . n
acest mod , clientul foloseste conexiunea de control pentru a trimite o comanda PASV la server i apoi
primete o adres IP a serverului i numrul portului de server de la serverul , [ 5 ] [ 6 ] , care folosete
apoi clientul pentru a deschide o conexiune de date de la un port client arbitrar la adresa IP a serverului i
numrul portului serverului primit . [ 7 ] Ambele moduri au fost actualizate n septembrie 1998 pentru a
sprijini IPv6 . Alte modificri au fost introduse la modul pasiv la acel moment , actualizarea se la modul
pasiv prelungit . [ 8 ]
Serverul raspunde prin conexiunea de control cu coduri de stare de trei cifre n ASCII cu un mesaj text
opional . De exemplu, " 200 " ( sau " 200 OK " ), nseamn c ultima comanda a fost de succes .

26

9.1.

Diagrama Use-Case

uc copierea informatiei din mail cu aj utorul serv erului FTP

Deschiderea client
brow ser

Client

Serv erul w eb
include
Copiere fisierilor din
mail

include

securitatea
informatiei TSG

include

include

Logare geosclml
Cerere de copiere
CSV

Accesarea mailului

include
Gestionarea bazei de
date
Serv erul FTp

Figura 31- Copierea informaiei din mail cu ajutorul serverului FTP


n diagrama dat se copie informia din email cu ajutorul serverului FTP. Clientul deschide browser-ul
acceseaz mail-ul si selecteaza mesajul prin intermediul serverului web deschide mesajul din baza de date
prin intermediul caruia mesajul sa gasit si din serverul FTP se descarca mesajul care are informatia dorit.
uc sistemul FTP serv er client

Logare
Accesarea serv erul
client FTP

Autorizare
extend

include

client
include
Incarca fisiere
include
include

Copiere fisier

Sterge fisiere
FTP serv er

Figura 32- Diagrama Use-Case Sistemul FTP server client


n diagrama dat are loc transferul de date , stergerea unui fisier,coipere ,descrcarea fiierilor in
server,din server.
27

uc transferul informatiei din serv erul local in serv erul FTP

Serv er local

Client

Conectarea la mailul
dat

Serv er FTP

include

Transferul informatiei

Figura 33 Diagrama Use-Case a transferul informaiei din serverul local in serverul FTP
n diagrama dat are loc transferul de date din serverul local in serverul FTP. Clientul transfar anumite
date prin intermediul internetului, internetul conecteaza clientul cu serverul local si mai apoi clinetul se
loghiaza la serverul local i mai apoi are loc transferul dat.
uc inregistrarea in sistemul FTP

logare

inregistrare

include

include

Accesarea FTP client

Client

serv erul HTP

include

preluarea IP DNS

Figura 34 Diagrama Use-Case a nregistrarii in sistemul FTP


n diagrama data are loc descrierea nregistrrii unui clinet in sistemul FTP. Clientul deschide browser-ul
procesul este preluat de client server si el transmite cerere de indentificare a clientului cu ajutorul DNS se
indentific IP dispozitivului care mai apoi are loc conectarea la serverul FTP care mai apoi serverul client
trimite cererea de inregistrare la sistemul dat la care aceste date sunt preluate in serverul FTP si are loc
verificarea si prelucrarea datelor la care trimite raspuns la cerere ca fiind acceptata sau respins.
28

9.2.

Diagrama de interaciune (de Secven i de Colaborare)


Diagrama de Secven

sd copierea informatiei din mail cu ajutorul FTP serv er


Client Browser

Serverul Web

Baze de Date

Serverul FTP

Client

deschidem browser()

accesare
mail()
acces confirmat()

selecteaza mesajul()

selecteaza mesajul()

a prelua mesajul()

mesaj gasit()

descarcarea mesajului()

prelucrarea fisierului()
incepe descarcarea ()

mesaj descarcat()

Figura 35 - Diagrama de secven a Copierea informaiei din email cu ajutorul FTp server
n diagrama dat se copie informia din email cu ajutorul serverului FTP. Clientul deschide browser-ul
acceseaz mail-ul si selecteaza mesajul prin intermediul serverului web deschide mesajul din baza de date
prin intermediul caruia mesajul sa gasit si din serverul FTP se descarca mesajul care are informatia dorit.

29

sd inregistrarea in sistemul serv erul FTP


Clientul FTP

Serverul FTP

DNS

Client

deschidem browser()

cerere de indentificare IP()


prelucrarea()
IP indentificat()

conecatarea prin porturi()

conectat()

introdu login ,parola()

date introduse()

date acceptate()

verificare()
bine ati venit logat()

logare cu succes()

Figura 36 Diagrama de secven a inregistrarii in sistemul FTP


n diagrama data are loc descrierea nregistrrii unui clinet in sistemul FTP. Clientul deschide browser-ul
procesul este preluat de client server si el transmite cerere de indentificare a clientului cu ajutorul DNS se
indentific IP dispozitivului care mai apoi are loc conectarea la serverul FTP care mai apoi serverul client
trimite cererea de inregistrare la sistemul dat la care aceste date sunt preluate in serverul FTP si are loc
verificarea si prelucrarea datelor la care trimite raspuns la cerere ca fiind acceptata sau respins.

30

sd lucru cu fisierele in serv erul FTP


Client FTP

Serverul FTP

Client

logare()

confirmare()

verificare()
acceptat()

acceptat()

incarcare fisier()

incarcare fisier()

incarcat()

incarcat()

descarcare
fisier()
descarcare fisier()

cautare fisier()
fisier gasit()

descarca fisierul()

Figura 37 - Diagrama de secven corespunzatoare lucrului cu fiierele in serverul FTP


n diagrama dat are loc transferul de date ,coipere ,descrcarea fiierilor in server,din server.

31

sd transferul de date din serv erul local in serv erul FTP


Dispozitivul det
ransfer

Internet

Serverul local de
fiere

Serverul FTP

Client

executa()

control la
conectare()
conectat()

introduceti
login,parola()
login, parola introduse()

logare()
client()

parola()

verificare()
validare conectat()

conectat()

conectat()

doresc sa transfer()
trimiterea cererii()

transfer acceptat()

incarca fisierul de transfer()

fisier incarcat()

transfer cu succes()

Figura 38 Diagrama de secventa corespunzatoare transferului de date din serverul local in serveul FTP

n diagrama dat are loc transferul de date din serverul local in serverul FTP. Clientul transfar anumite
date prin intermediul internetului, internetul conecteaza clientul cu serverul local si mai apoi clinetul se
loghiaza la serverul local i mai apoi are loc transferul dat.

32

Diagrama de colaborare

Figura 39 - Diagrama de colaborare corespunztoare nregistrrii in serverul FTP


1:Clientul deschide browser
2:Indentificarea IP dispozitivului cu care
acceseaza clientul
3:Prelucrarea
4:raspuns la indentificare
5:conectarea la server prin porturi
6:raspuns la conectare

7:raspuns la client ca conectat


8:introducerea datelor
9: transmiterea datelor la server
10:verificare
11:transmiterea raspunsului la inregistrare
12: raspuns conectat

Figura 40 Diagrama de colaborare corespunztoare copierii informaiei din email cu ajutorul FTP
server
1:Clientul deschide browser
2:Accesarea mailului
3:Raspuns la accesare
4:Raspuns acceptat
5:Selecteaza mesajul care doreste sa descarce
6:Transmiterea mesajului de transfer

7:Treluarea mesajului din baza de date


8:Mesaj preluat
9: Descarcarea mesajului
10:Prelucrarea mesajului
11:Transmite raspuns la descarcare
12: ncepe descarcarea
33

analysis Business Process Model

logare

client

Client FTP

lucru cu
fisiere

utilizatori

Serv erul FTP

Descarcare
fisiere

Incarcare
fisiere

Figura 41 Diagrama de colaborare tip de specificare corespunztoare lucrului cu fisierele in serverul


FTP
n diagrama dat are loc transferul de date ,coipere ,descrcarea fiierilor in server ,din server prin
intermediul conectarii la aplicatia serverului.

analysis transferul informatiei din serv er local in serv erul FTP

Dispozitiv de
transfer

Internet

Trimite
cererea de
transfer

Incarcarea
fisierelor de
transfer

Serv erul local de


fisiere

Serv erul FTP

Figura 42 Diagrama de colaborare tip de specificare corespunztoare transferului de date din serverul
local in serverul FTP
n diagrama dat are loc transferul de date din serverul local in serverul FTP. Clientul transfar anumite
date prin intermediul internetului, internetul conecteaza clientul cu serverul local si mai apoi clinetul se
loghiaza la serverul local i mai apoi are loc transferul dat.

34

9.3.

Diagrama Claselor
analysis Business Process Model

Client
-

adresa: int
ID: int
nr_telefon: int
nume: int
prenume: int

+
+
+

acceseaza() : void
modifca() : void
vizualizeaza() : void

Client FTP
+
+
+

autentifica() : void
citeste date() : void
indentifica () : void
Serv erul FTP
-

porturi: int
volum de date: int

+
+
+

autentifica() : void
executa operatii() : void
transfera() : void

Dispozitiv ul DNS
+
+

autentifica IP() : void


translateaza() : void

Figura 43 Diagrama claselor corespunztoare nregistrrii in serverul FTP


n diagrama data are loc descrierea nregistrrii unui clinet in sistemul FTP. Clientul deschide browser-ul
procesul este preluat de client server si el transmite cerere de indentificare a clientului cu ajutorul DNS se
indentific IP dispozitivului care mai apoi are loc conectarea la serverul FTP care mai apoi serverul client
trimite cererea de inregistrare la sistemul dat la care aceste date sunt preluate in serverul FTP si are loc
verificarea si prelucrarea datelor la care trimite raspuns la cerere ca fiind acceptata sau respins.
class Class Model

client
client brow ser
-

IP: int
nr_telefon: int
nume: int
prenume: int

+
+

acceseaza() : void
selecteaza() : void

interfata: int

afiseaza() : void

serv er w eb

Serv er FTP

date: int
informatii: int

+
+
+

accesare() : void
conectare() : void
transmite() : void

baze de date

aplicatii: int

tabel de alocare: int

+
+
+
+

autentificare() : void
executare() : void
transfera() : void
verificare() : void

+
+
+

gestioneaza date() : void


pastreaza date() : void
verifica date() : void

Figura 44 Diagrama claselor corespunztoare copierii informaiei din email cu ajutorul FTp server
n diagrama dat se copie informia din email cu ajutorul serverului FTP. Clientul deschide browser-ul
acceseaz mail-ul si selecteaza mesajul prin intermediul serverului web deschide mesajul din baza de date
prin intermediul caruia mesajul sa gasit si din serverul FTP se descarca mesajul care are informatia dorit.
35

class Class Model

Client
-

ID: int
nr_telefon: int
nume: int
prenume: int

+
+
+

acceseaza () : void
modifica() : void
selecteaza() : void

brow ser
-

interfata: int

afiseaza() : void

Client FTP
+
+
+

autentifica() : void
citeste date() : void
indentifica() : void

Serv erul FTP


-

aplicatii: int
porturi: int
volum de date: int

+
+
+

autentifica() : void
executa() : void
transfera() : void

Figura 45 Diagrama de clase tip de specificare corespunztoare lucrului cu fisierele in serverul FTP
n diagrama dat are loc transferul de date ,coipere ,descrcarea fiierilor in server ,din server prin
intermediul conectarii la aplicatia serverului.
class Class Model

ID: int
nr_telefon: int
nume: int
prenume: int

+
+
+

acceseaza() : void
modifica() : void
selecteaza() : void

w eb serv er

dispozitiv ul de transfer

client

transfera info() : void

pagini de informatii: int

+
+
+

autentifica() : void
conecteaza() : void
transmite() : void

serv erul FTP


-

aplicatii: int
porturi: int
volum de date: int

+
+
+

autentificare() : void
executa() : void
transfera() : void

serv erul local de fisiere


+
+
+

descarca date() : void


incarca date() : void
transfera() : void

Figura 46 Diagrama de clasa corespunztoare transferului de date din serverul local in serverul FTP
n diagrama dat are loc transferul de date din serverul local in serverul FTP. Clientul transfar anumite
date prin intermediul internetului, internetul conecteaza clientul cu serverul local si mai apoi clinetul se
loghiaza la serverul local i mai apoi are loc transferul dat.
36

9.4.

Diagrama de stare

analysis clietul acceseaza

clientul
acceseaza
unei pagini w eb
[exista conexiune]

[nu exista conexiune la internet]

accesarea mailului
eroare la conexiune

selectarea mesaj ului

[date prezente]

v erificarea conexiunii
la internet

[mesajul nu exista in baza de date]

nu poate fi descarcat
mesaj descarcat

Final

Final
Final

Figura 48 - Diagrama de stare corespunztoare copierii informaiei din email cu ajutorul FTp server
n diagrama dat se copie informia din email cu ajutorul serverului FTP. Clientul deschide browser-ul
acceseaz mail-ul si selecteaza mesajul prin intermediul serverului web deschide mesajul din baza de date
prin intermediul caruia mesajul sa gasit si din serverul FTP se descarca mesajul care are informatia dorit.

37

analysis clietul acceseaza

clientul
deschide
accesarea unei pagini
web

conectarea la serv er

[server
supraincarcat]

[server liber]

eroare la conexiune
autentificare la serv er

[date introduse corect]

[nr<=3]

[date incorecte]
incercare noua

logat

incercare noua
[nr>3]

incercare noua dupa


ora 00:00

Final

Final

Figura 49 - Diagrama de stare Diagrama de stare corespunztoare nregistrrii in serverul FTP


n diagrama data are loc descrierea nregistrrii unui clinet in sistemul FTP. Clientul deschide browser-ul
procesul este preluat de client server si el transmite cerere de indentificare a clientului cu ajutorul DNS se
indentific IP dispozitivului care mai apoi are loc conectarea la serverul FTP daca exista conexiune la
internet se conecteaza , care mai apoi serverul client trimite cererea de inregistrare la sistemul dat la care
aceste date sunt preluate in serverul FTP si are loc verificarea si prelucrarea datelor la care trimite
raspuns la cerere ca fiind acceptata sau respins.

38

analysis clietul acceseaza

clientul
acceseaza
aplicatia client FTP

[nr<=3]
autentificare
[parola si login corect]
logat

[login sau parola incorecta]


incercati din nou
[nr>3]

descarcarea unui fisier


din serv erul FTP

incarcarea unui fisier


in serv erul FTP

incercati din nou miine

Final

Final

Figura 50- Diagrama de stare corespunztoare lucrului cu fisierele in serverul FTP


n diagrama dat are loc transferul de date ,coipere ,descrcarea fiierilor in server ,din server prin
intermediul conectarii la aplicatia serverului.

39

analysis clietul acceseaza

Initial
conectarea la
protocolul de transfer
FTP
[nu exista conexiune]
[exista conexiune]

conectare

verificarea conexiunii
la internet

introducerea datelor de
autentificare

Final

[date introduse corect]

[date introduse incorect]


eroare la logare

logat

[nr.>3]
executarea transferului

Final

[nr.<=3]
incercare noua

restabilirea datelor de
autentificare

introducerea emailul

trimiterea datelor pe
mail

incercare noua

Figura 51-Diagrama de stare corespunztoare transferului de date din serverul local in serverul FTP
n diagrama dat are loc transferul de date din serverul local in serverul FTP. Clientul transfar anumite
date prin intermediul internetului, internetul conecteaza clientul cu serverul local si mai apoi clinetul se
loghiaza la serverul local i mai apoi are loc transferul dat.

40

9.5.

Diagrama de activiti

analysis clietul acceseaza

clientul
deschide
accesarea unei pagini
w eb

conectarea la serv er

[server supraincarcat]

[server liber]

eroare la conexiune
autentificare la serv er
incercare noua
[date introduse corect]

[dae introduse incorect]


incercare noua

logat

[nr>3]

[nr<=3]

incercare noua dupa


ora 00:00

Final

Figura 52 Diagrama de activitate corespunztoare nregistrrii in serverul FTP


n diagrama data are loc descrierea nregistrrii unui clinet in sistemul FTP. Clientul deschide browser-ul
procesul este preluat de client server si el transmite cerere de indentificare a clientului cu ajutorul DNS se
indentific IP dispozitivului care mai apoi are loc conectarea la serverul FTP care mai apoi serverul client
trimite cererea de inregistrare la sistemul dat la care aceste date sunt preluate in serverul FTP si are loc
verificarea si prelucrarea datelor la care trimite raspuns la cerere ca fiind acceptata sau respins.

41

analysis clietul acceseaza

clientul
acceseaza
aplicatia client FTP

autentificare
[parola si login corect]

[login sau parola incorecta]

logat

incarcarea unui fisier


in serv erul FTP

incercare noua

descarcarea unui fisier


din serv erul FTP

Final

Figura 53 Diagrama de activitate corespunztoare lucrului cu fisierele in serverul FTP


n diagrama dat are loc transferul de date ,coipere ,descrcarea fiierilor in server ,din server prin
intermediul conectarii la aplicatia serverului.

42

analysis Business Process Model


client

deschide brow ser

internet

mail

conexiune la internet

[exista conexiune]
[nu e conex]

accesarea emailului

eroare

selectarea mesaj ului

descarcare mesaj

ActivityFinal

Figura 54 Diagrama de activitate corespunztoare copierii informaiei din email cu ajutorul FTp server
n diagrama dat se copie informia din email cu ajutorul serverului FTP. Clientul deschide browser-ul
acceseaz mail-ul si selecteaza mesajul prin intermediul serverului web deschide mesajul din baza de date
prin intermediul caruia mesajul sa gasit si din serverul FTP se descarca mesajul care are informatia dorit.

43

analysis Business Process Model


utilizatori

Protocolul FTP

Internet

client FTP

ActivityInitial

conectare la protocolul
FTP

conectarea la internet

conectat
[exista conexiune]

[nu este conexiune]


eroare

introducerea datelor
eroare

[date introduse incorect]

[date corecte]
executare transfer

logat

transferat

ActivityFinal

Figura 55 Diagrama de activitate corespunztoare transferului de date din serverul local in serverul FTP
n diagrama dat are loc transferul de date din serverul local in serverul FTP. Clientul transfar anumite
date prin intermediul internetului, internetul conecteaza clientul cu serverul local si mai apoi clinetul se
loghiaza la serverul local i mai apoi are loc transferul dat.

44

9.6.

Diagrama componentelor

Figura 56 Reprezentarea componentelor conexiunii cu serverul FTP.


Prinicipale componente ale sistemului dat sunt statiile de lucru care face conexiunea cu componenta
server FTP prin intermediul pachetului de dispozitive de comunicare(modem,router).

Figura 57 Componente dependente ale procedurilor de sistem si componentele serverului FTP.


Aici sunt reprezentate doua pachete (Client FTP, Server FTP). Client FTP contine trei
componente(library, command line, gui) care deinde de procedurile serverului FTP.

45

Figura 58 Componentele de baza a sistemului FTP server


Dispozitivele telefon,tableta si pc sunt dependente de pachetul internet care are in componenta sa 2
componente (GUI si pagini web) care la rindul sau este in dependenta de firewall si deacum aceasta este
dependenta de pachetul server de aplicatii care are in componenta sa 2 componente(server de baze de date
si serverul FTP).
9.7.

Diagrama de amplasare

deployment Deployment Model

client 1

w eb serv er

client 2

client FTP

device
comunication
dev ice

FTP serv er

managing users

client 3

Figura 59 Amplasarea sistemului serverul FTP


Sistemul informational serverul FTP ca si client FTP este situat in orecare server web. Acest server ca la
rindul sau este conectat la un dispozitiv de comunicare care este indentificat cu ajutorul DNS care la
rindul sau ca clientii sa se poata conecta la server pentru a obtine informatiile dorite se conecteaza cu
ajutorul dispozitivului dat si care obtin conexiunea.
46

10. Concluzie
n urma efecturii acestei lucrri am ajuns la concluzia c:
Proiectarea nu este desenarea diagramelor, diagramele pur i simplu reflect rezultatele
proiectrii.
La proiectarea unui sistem complex e important de a-l studia din diferite unghiuri de vedere
att din punct de vedere al structurii logice / fizice, ct i al semanticii statice / dinamice.

Sistemul de notri al proiectrii orientate pe obiecte include 7 diagrame

Diagrama claselor arat ce clase exist i legtura dintre ele n structura logic a sistemului. O

diagram a claselor concret este un unghi de vedere al structurii depline a claselor sistemului.

Diagrama componentelor arat repartizarea claselor i obiectelor dup module n structura fizic

a sistemului. Diagrama componentelor este un racurs asupra arhitecturii proceselor sistemului.

Diagrama strilor i activitilor prezint : 1. spaiul strilor exemplarelor clasei date; 2.

evenimentele care provoac tranziia dintr-o stare n alta, 3. aciunile care au loc la schimbarea strii.

Diagrama interaciunilor permite urmrirea ndeplinirii scenariului.

11. Bibliografie
1)
2)
3)
4)

Materiarul didactic transmis de profesor


www.agora.ro
www.interface.ru
www.citforum.ru -

5) www.RationRose.com
6) www.magicdraw.com
7) www.google.com

47