Lucrare de Curs AMSI_elena

7/26/2019 Lucrare de Curs AMSI_elena

1/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


2/47

2

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-------------------------------------------------------------------------------------------- 4711. Bibliografie------------------------------------------------------------------------------------------47


3/47

3

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 limb ajul

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 ajutla 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.
http://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/dsecv.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/dcolab.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/dclas.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/dstare.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/diagcomp.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/constructie.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/diagobiect.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/activ.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/activ.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/diagobiect.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/constructie.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/diagcomp.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/dstare.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/dclas.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/dcolab.htmhttp://www.elcom.pub.ro/elcom/Romana/Cursuri/ISW/UML_OT/dsecv.htm


4/47

4

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 informatical 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

indeplineascsistemul 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 poartnumele

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 unrol poate caracteriza mai multe persoane. Reprezentare grafica actorilor in UML este

un omulestilizat avand la subsol un text ce reprezintrolul jucat de actor (figura 1).

Figura 1. Reprezentarea grafica actorilor in UML

Determinarea actorilor se face rspunznd la ntrebrile:

-

cineeste dorete sau interesat de informaiile aflate in sistem,

- cinemodificdate,

- cinese interacioneazcu 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 tabelde evenimente permite

de asemenea detectarea tuturor cazurilor de utilizare a sistemului.

Cazurile de utilizarereprezint 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


5/47

5

- trebuie s ndeplineasc anumite scopuri de logica 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 cesistemul 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 grafica cazurilor de utilizare in UML se realizeazprin intermediul unui oval avand la

baznumele 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 (sauBCE - Basic Course of Events)

Ci alternative (sauACE-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 (stereotipul este un concept introdus

in UML care permite extinderea elementelor de modelare de baza pentru a creea noii elemente).


6/47

6

- 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 .

Figura 4. Reprezentarea grafica a relatiilor de extindere si utilizare

intre cazuri de utilizare

Relaii ntre actori (figura 5):- relaia de generalizare: semnificfaptul 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 fara 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.


7/47

7

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).

Unscenariureprezint 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 unuicaz de utilizare.

Reprezentarea grafic a obiectelor n diagrama de secven se realizeaz ca nfigura 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).
http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs2.htm#FigObiecthttp://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs2.htm#FigObiecthttp://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs2.htm#FigObiecthttp://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs2.htm#FigObiect


8/47

8

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, CursuriCtleste clas de control, iar CursOptionaleste clas entitate).

Figura 8.


9/47

9

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 cumse realizeaza in detaliu o anumita functionalitate.

'Cum se modeleaz scenariile ce conin logic condiional?' n cazul n care logica este simpl, se

construieteo 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 a semnala o 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 theni 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).


10/47

10

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 dintreclase.

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.


11/47

11

-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 wrapperpeste 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 activitatean interiorul aplicaiei. Se creaz cte o clas

controllerpentru 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.


12/47

12

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


13/47

13

-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 Anexa 1

Element Descriere Notaie

ClasO clas este reprezentat printr-un dreptunghi cu treicompartimente: n cel de sus se trece numele clasei,n mijloc setrec atributeleclasei iar jos se trec operaiilespecifice clasei.

Motenire

Motenirea este o relaie care indic faptul c o clasmotenete caracteristicile unei clase printe. Sensul sgeiiindic sensul n care se poate spune despre clasa copil c este

o, sau este de tipul clas printe.

Asociere

Asocierea este o relaie generic ntre dou clase. Aceste relaiipot fi de tipurile pot defini i regulile numerice de asociere (unula unu, unu la mai muli, mai muli la mai muli).

DependenAtunci cnd o clas depinde de o alt clas, n sensul c utilizeazacea clas ca i atribut al su, se folosete relaia de dependen.

Agregare Agregarea indic o relaie de tip ntreg-parte (se poate spunedespre clasa printe c are clase de tip copil). n aceast relaie,clasa copil poate exista i fr clasa printe.

CompoziieAceast relaie deriv din agregare dar se utilizeaz atunci cnd oclas copil nu poate exista dect n cazul existenei clasei printe.


14/47

14

5. Diagrama de stare

Cazurile de utilizare i scenariile reprezint modaliti de descriere a comportamentului sistemelor

informatice (vzut ca interaciuni ntre obiecte). n anumite cazuri ns este necesar studierea

comportamentului n interiorul unui obiect. 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.

Ostare(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 invariantde 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 tranziieexprim 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-strilecorespunztoare.


15/47

15

Figura 14.Etichetarea tranziiilor n hrile de stri UML

Hrile de stri permit modelarea de comportamente paralele ale unui obiect prin intermediulstrilor

ortogonale(denumite i AND-stri sau stri concurente). Strile ortogonale suntformate din mai multe

componente ortogonale, fiecare dintre acestea coninnd diverse sub-stri. Un obiect aflat ntr-o stareortogonal 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 situa ii 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 destinaieeste o stare compus. Se reprezint grafic sub forma unui cerc plin.


16/47

16

- 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 aceaststare compus, ea fiind dat mai apoi de ultima sub-stare

activ. n figura 16 o prim tranziie spre stareaPornitaimplic activarea sub-striiNormal, urmtoarele

tranziii activnd sub-starea (NormalsauMarsarier) activ n momentul ultimei prsiria striiPornita.

Pseudostrile istoric au dou variante: superficialeiprofunde-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),

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

Figura 16.Pseudostrile ramificaie (a),fork(b) ijoin(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.


17/47

17

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)


18/47

18

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 softwareci 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, F luxur il e de control si

Fluxur il e 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


19/47

19

Fluxur il e 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 destinatieimediat dupa finalizarea activitatiisursa. Fluxurile de control mai

poarta numele de tranzitii implicite sau automatedeoarece 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

initialesi finalecu 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


20/47

20

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.


21/47

21

O deciziepresupune 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 declansareatuturor 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 activitateaListeaza

Informatiasi pentru a monitoriza alte cereri de listare in timpul tratarii cererii curente, prin intermediul


22/47

22

activitatiiMonitorizarea Cererilor de Listare. Odata ce ambele activitati s-au terminat, un contabilpoate

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. Acestedependente 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


23/47

23

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 ()

- subprograme ()

- pachete ()

- librarii cu legare dinamica ()

- procese ( )

- executabile ( )


24/47

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 desfurarepot 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 sau prin ncuibrirea grafic a simboluluicomponentei n

cadrul simbolului ce reprezint nodul (figura 6).

Figura 28.Diagrama de desfurarepentru o aplicatie

de gestiune a biletelor de calatorie cu avionul


25/47

25

Migrarea instanelor de componente dintr-un nod n altul, sau migrarea obiectelor de la o component la

alta poate fi implementat grafic utiliznd stereotipul 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 desfurareparticulare. Aceste diagrame de

desfurarecontin noduri de doua tipuri: procesoare si dispozitive. Intre aceste noduri se pot trasa relatii

de conexiune.

Procesoarelereprezinta 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

Dispozitivelereprezinta componente hard fara putere de calcul. Numele asociat unuidispozitiv 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 desfurarea unui sistem informatic oarecare


26/47

26

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 bazatpe 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 pasivpoate 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 asprijini 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 .


27/47


28/47

28

uc transferul informatiei din se rverul local in serv erul FTP

Client

Transferul informatiei

Server local

Serv er FTPConectarea la mailul

dat

include

Figura 33Diagrama Use-Case a transferul informaiei din serverul local in serverul FTP

n diagrama dat are loc transferul de date din serverul local in serverulFTP. Clientul transfar anumitedate 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

Client

Accesarea FTP client

preluarea IP DNS

serv erul HTP

logareinregistrare

includeinclude

include

Figura 34Diagrama Use-Case a nregistrarii in sistemul FTP

n diagrama data are loc descrierea nregistrrii unui clinet in sistemul FTP. Clientul deschide browser-ulprocesul 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 locverificarea si prelucrarea datelor la care trimite raspuns la cerere ca fiind acceptata sau respins.
ftp://ftp.clientul/ftp://ftp.clientul/


29/47

29

9.2. Diagrama de interaciune (de Secven i de Colaborare)

Diagrama de Secven

sd copierea informatiei din mail cu aj utorul FTP server

Client

Client Browser Serverul Web Baze de Date Serverul FTP

deschidem browser()

accesare

mail()

acces confirmat()

selecteaza m esajul ()

selecteaza mesajul()

a prelua mesajul()

mesaj gasit()

descarcarea mesajulu i()

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-ulacceseaz 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.


30/47

30

sd inregistrarea in sistemul serv erul FTP

Client

Clientul FTP Serverul FTP DNS

deschidem browser()

cerere de indentifi care IP()

prelucrarea()

IP indentifi cat()

conecatarea prin porturi()

conectat()

introdu login ,parola()

date introduse()

date acceptate()

verificare()

bine ati venit logat()

logare cu succes()

Figura 36Diagrama de secvena inregistrarii in sistemul FTP


indentific IP dispozitivului care mai apoi are loc conectarea la serverul FTP care mai apoi serverul clienttrimite 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.


31/47

31

sd lucru cu fisierele in serverul FTP

Client

Client FTP Serverul FTP

logare()

confirmare()

verificare()

acceptat()

acceptat()

incarcare fisier()

incarcare fi sier()

incarcat()

incarcat()

descarcare

fisier()

descarcare fisier()

cautare fi sier()fisier gasit()

descarca fi sierul ()

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.


32/47

32

sd transferul de date din serverul local in serv erul FTP

Client

Dispozitivul det

ransfer

Internet Serverul local de

fiere

Serverul FTP

executa()

control laconectare()

conectat()

introduceti

login,parola()

login, parola introduse()

logare()

client()

parola()

verificare()

validare conectat()

conectat()

conectat()

doresc sa transfer()

trimiterea cererii()

transfer acceptat()

incarca fi sierul de transfer()

fisier i ncarcat()

transfer cu succes()

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

n diagrama dat are loc transferul de date din serverullocal in serverulFTP. Clientul transfar anumitedate prin intermediul internetului, internetul conecteaza clientul cu serverul local si mai apoi clinetul se



33/47

33

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 40Diagrama de colaborare corespunztoare copierii informaiei din email cu ajutorul FTPserver

1:Clientul deschide browser

2:Accesarea mailului

3:Raspuns la accesare

4:Raspuns acceptat

5:Selecteaza mesajul care doreste sa descarce6:Transmiterea mesajului de transfer

7:Treluarea mesajului din baza de date

8:Mesaj preluat

9: Descarcarea mesajului

10:Prelucrarea mesajului

11:Transmite raspuns la descarcare12: ncepe descarcarea


34/47

34

analysis Business Process Model

logare Client FTP

Serv erul FTP

Incarcare

fisiere

Descarcare

fisiere

lucru cu

fisiere

client

utilizatori

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

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

analysis transferul informatiei din server local in serv erul FTP

Dispozitiv de

transfer

Internet Serv erul FTPIncarcarea

fisierelor de

transfer

Serverul local de

fisiere

Trimite

cererea de

transfer

Figura 42 Diagrama de colaborare tip de specificare corespunztoare transferului de date din serverullocal in serverul FTP


ftp://ftp.clientul/ftp://ftp.clientul/ftp://ftp.clientul/


35/47

35

9.3. Diagrama Claselor


Client

- adresa: int

- ID: int

- nr_telefon: int

- nume: int

- prenume: int

+ acceseaza() : void

+ modi fca() : void

+ vizual izeaza() : void

Client FTP

+ autenti fica() : void

+ citeste date() : void

+ indentifica () : void

Serv erul FTP

- porturi: int

- volum de date: int

+ autenti fica() : void

+ executa operatii () : void

+ transfera() : void

Dispozitivul DNS

+ autenti fica IP() : void

+ translateaza() : void

Figura 43Diagrama claselor corespunztoare nregistrrii in serverul FTP


indentific IP dispozitivului care mai apoi are loc conectarea la serverul FTP care mai apoiserverul clienttrimite cererea de inregistrare la sistemul dat la care aceste date sunt preluate in serverul FTP si are loc


class Class Model

client

- IP: int

- nr_telefon: int

- nume: int

- prenume: int


+ selecteaza() : void

client browser

- interfata: int

+ afiseaza() : voidserver w eb

- date: int

- informatii: int

+ accesare() : void

+ conectare() : void

+ transmite () : void

baze de date

- tabel de alocare: int

+ gestioneaza date() : void

+ pastreaza date() : void

+ verifica date() : void

Server FTP

- aplicatii: int

+ autenti ficare() : void

+ executare() : void


+ verificare() : void

Figura 44Diagrama 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-ulacceseaz mail-ul si selecteaza mesajul prin intermediul serverului web deschide mesajul din baza de dateprin intermediul caruia mesajul sa gasit si din serverul FTP se descarca mesajul care are informatia dorit.


36/47

36

class Class Model

Client

- ID: int

- nr_telefon: int

- nume: int

- prenume: int

+ acceseaza () : void

+ modifi ca() : void


browser

- interfata: int

+ afiseaza() : void

Serv erul FTP

- apli catii: int

- porturi: int


+ autentifi ca() : void

+ executa() : void


Client FTP

+ autentifica() : void

+ citeste date() : void

+ indenti fica() : void

Figura 45Diagrama de clase tip de specificare corespunztoare lucrului cu fisierele in serverul FTP


class Class Model

client

- ID: int- nr_telefon: int

- nume: int

- prenume: int


+ modi fica() : void


dispozitivul de transfer

+ transfera info() : void

web server

- pagini de informatii: int

+ autentifi ca() : void

+ conecteaza() : void

+ transmi te() : void

serv erul FTP

- aplicatii: int

- porturi: int


+ autentifi care() : void

+ executa() : void


serv erul local de fisiere

+ descarca date() : void

+ incarca date() : void


Figura 46Diagrama de clasa corespunztoare transferului de date din serverul local in serverul FTP

n diagrama dat are loc transferul de date din serverul local in serverulFTP. Clientul transfar anumite

date prin intermediul internetului, internetul conecteaza clientul cu serverul local si mai apoi clinetul seloghiaza la serverul local i mai apoi are loc transferul dat.


37/47

37

9.4. Diagrama de stare

analysis clietul acceseaza

clientulacceseaza

Final

unei pagini web

accesarea mailului

eroare la conexiune

selectarea mesajului

mesaj descarcatnu poate fi descarcat

verificarea conexiunii

la internet

Final

Final

[mesajul nu exista in baza de date][date prezente]

[nu exista conexiune la internet][exista conexiune]

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-ulacceseaz 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.


38/47

38


clientul

deschide

Final

accesarea unei pagini

web

autentificare la server

eroare la conexiune

logatincercare noua

incercare noua

conectarea la server

Final

incercare noua dupa

ora 00:00

[date i ncorecte][date introduse corect]

[server

supraincarcat][server liber]

[nr>3]

[nr


39/47

39


clientul

acceseaza

Final

aplicatia client FTP

incercati din nou

Final

logat

incarcarea unui fisier

in serv erul FTP

descarcarea unui fisier

din serv erul FTP

incercati din nou miine

autentificare[nr3]

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



40/47

40


conectarea la

protocolul de transfer

FTP

verificarea conexiunii

la internetconectare

introducerea datelor de

autentificare

logateroare la logare

Final

incercare nouarestabilirea datelor de

autentificare

introducerea emailul

trimiterea datelor pe

mail

incercare noua

executarea transferului

Final

Initial

[nr.3]

[date introduse incorect]

Figura 51-Diagrama de stare corespunztoare transferului de date din serverul local in serverul FTP




41/47

41

9.5. Diagrama de activiti


clientul

deschide

accesarea unei pagini

web

autentificare la server

eroare la conexiune

logatincercare noua

incercare noua

conectarea la serve r

Final

incercare noua dupa

ora 00:00

[nr3]

[dae introduse incorect]

Figura 52Diagrama de activitate corespunztoare nregistrrii in serverul FTP


indentific IP dispozitivului care mai apoi are loc conectarea la serverul FTP care mai apoi serverul clienttrimite cererea de inregistrare la sistemul dat la care aceste date sunt preluate in serverul FTP si are loc



42/47

42


clientul

acceseaza

Final

aplicatia client FTP

incercare noualogat

incarcarea unui fisier

in serv erul FTPdescarcarea unui fisier

din serverul FTP

autentificare

[login sau parola incorecta][parola si login corect]

Figura 53Diagrama de activitate corespunztoare lucrului cu fisierelein serverul FTP



43/47

43


mailinternetclient

deschide browser conexiune la internet

accesarea emailului

eroare

selectarea mesaj ului

descarcare mesaj

Acti vityFina l

[nu e conex]

[exista conexiune]

Figura 54Diagrama de activitate corespunztoare copierii informaiei din email cuajutorul FTp server

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


44/47

44


client FTPInternetProtocolul FTPutilizatori

Acti vity Ini tia l

conectare la protocolul

FTP

conectarea la internet

eroare

conectat

introducerea datelor

eroare

executare transfer

Acti vityFi na l

logat

transferat

[date i ntroduse incorect]

[nu este conexiune]

[date corecte]

[exista conexiun e]

Figura 55Diagrama de activitate corespunztoare transferului de date din serverul local in serverul FTP




45/47

45

9.6. Diagrama componentelor

Figura 56Reprezentarea 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 57Componente 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.


46/47

46

Figura 58Componentele 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

device

comunication

device

client 2

client 3

web server

client FTP FTP server

managing users

Figura 59Amplasarea 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.


47/47

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)

Materiarul didactic transmis de profesor

2) www.agora.ro

3)

www.interface.ru

4) www.citforum.ru -

5) www.RationRose.com

6) www.magicdraw.com

7) www.google.com
http://www.agora.ro/http://www.agora.ro/http://www.interface.ru/fset.asp?Url=/rational/suite/Suite.htmhttp://www.interface.ru/fset.asp?Url=/rational/suite/Suite.htmhttp://www.citforum.ru/http://www.rationrose.com/http://www.rationrose.com/http://www.citforum.ru/http://www.interface.ru/fset.asp?Url=/rational/suite/Suite.htmhttp://www.agora.ro/

Lucrare de Curs AMSI_elena

Documents

Transcript of Lucrare de Curs AMSI_elena