Ministerul Educației al Republicii Moldova Universitatea Tehnică a Moldovei Facultatea Calculatoare Informatică şi Microelectronică Catedra Automatică şi Tehnologii Informaţionale
PROIECT DE CURS
Disciplina: Analiza şi modelarea sistemelor informaţionale Tema: Analiza şi modelarea unui FTP server
A efectuat:
studenta grupei TI-111 Damaschin Elena
A verificat:
lector superior Nina Sava
Chișinău 2013
Cuprinsul
1.
Introducere ---------------------------------------------------------------------------------------------- 3
2.
Diagrama Use-Case ----------------------------------------------------------------------------------- 4
3.
Diagrama de interacţiune (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 desf ăşurare ăşurare --------------------------------------------------------------------------- 24
9.
Modelarea Serverului FTP------------------------------------------------------- -------------------26 9.1.
Diagrama Use-Case ---------------------------------------------------------------------------- 27
9.2.
Diagrama Diag rama de interacţiune (de Secvenţă şi de Colaborare) ----------------------------- 29
9.3.
Diagrama Claselor ------------------------------------------------------------------------------ 35
9.4.
Diagrama de stare ------------------------------------------------------------------------------ 37
9.5.
Diagrama de activităţi ------------------------------------------------------------------------- 41
9.6.
Diagrama componentelor --------------------------------------------------------------------- 45
9.7.
Diagrama de amplasare -------------------------------------------------------------------------- 46
10.
Concluzie -------------------------------------------------------------------------------------------- 47
11.
Bibliografie ------------------------------------------------------------------------------------------47
2
Cuprinsul
1.
Introducere ---------------------------------------------------------------------------------------------- 3
2.
Diagrama Use-Case ----------------------------------------------------------------------------------- 4
3.
Diagrama de interacţiune (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 desf ăşurare ăşurare --------------------------------------------------------------------------- 24
9.
Modelarea Serverului FTP------------------------------------------------------- -------------------26 9.1.
Diagrama Use-Case ---------------------------------------------------------------------------- 27
9.2.
Diagrama Diag rama de interacţiune (de Secvenţă şi de Colaborare) ----------------------------- 29
9.3.
Diagrama Claselor ------------------------------------------------------------------------------ 35
9.4.
Diagrama de stare ------------------------------------------------------------------------------ 37
9.5.
Diagrama de activităţi ------------------------------------------------------------------------- 41
9.6.
Diagrama componentelor --------------------------------------------------------------------- 45
9.7.
Diagrama de amplasare -------------------------------------------------------------------------- 46
10.
Concluzie -------------------------------------------------------------------------------------------- 47
11.
Bibliografie ------------------------------------------------------------------------------------------47
2
1. Introducere
Este de mult știut faptul că în trecut programatorii dezvoltau programe fără 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, pe ntru a obtine o ate nție mărită din partea diverşilor dezvoltatori. Aceste etape au fost ignorate în trecut, dar în prezent orice dezvoltator recunoaşte importanța 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 modela re 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 funcţionează pe analiza si proiectarea obiectelor cu un limbaj corespunză tor 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ă notaţ iile UML.
Notațiile UML constituie un element esenţ ial al limbajului pentru realizarea propriu-zisa a modelării și anume partea reprezentă rii grafice pe care se bazeaza orice limbaj de modelare. Modelar ea ea în acest limbaj se realizează prin combinarea notaţiilor 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 secventa, diagrama de colaborare, diagrama colaborare, diagrama de clase (cea mai utilizata), diagrama utilizata), diagrama de stari, diagrama de componente, diagrama componente, diagrama de constructie, diagrama constructie, diagrama de obiecte, diagrama obiecte, diagrama de activitati. urmează
În cele ce
vor fi prezentate notaţ iile UML care vor fi grupate dupa diagramel e corespunzătoare fiecarei
notaţii în parte.
3
2. Diagrama Use-Case
Una dintre condiţiile ce trebuie indeplinite ca un proiect sa aibă succes este aceea ca cerinţele proiectului
să fie definite într -o manieră care să permită o uşoară înţelegere, indiferent de nivelul de
pregătire informatică al celui care este implicat în proiect. De asemenea, modificările ce apar pe parcurs în cerinţe trebuie să fie cu uşurinţă asimilate de către membrii echipei de dezvoltare. Diagramele de cazuri de utilizare au rolul de a reprezenta intr-o
formă grafică funcţionalităţ ile pe care trebuie sa le
indeplinească sistemul informatic in faza sa finală . De aceea modelul realizat de diagramele de cazuri de utilizare alături de documentele de descriere succinta a fiecă rui caz de utilizare determinat poartă numele de model al cerinţelor . Diagramele de cazuri de
utilizare sunt formate din două categorii de entitaţ i (actori si cazuri de
utilizare) si relaţii intre acestea. Actorii
sunt roluri jucate de diverse persoane sau sisteme informatice şi care interacţionează 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 răspunzând la întrebările: -
cine este doreşte sau interesat de informaţiile aflate in sistem,
-
cine modifică date,
-
cine se interacţionează cu sistemul.
Raspunsurile
concrete la cele patru intrebă ri de mai sus se introduc intr-o asa-numita tabelă de
evenimente cu 4 coloane: Subiect(actor), Verb, Ob iect, Frecvenţă.
Aceasta tabelă de evenimente permite
de asemenea detectarea tuturor cazurilor de utilizare a sistemului. Cazurile de utilizare
reprezintă secvenţe de tranzacţii ce au loc în dialog cu sistemul şi care sunt înrudite
din punct de vedere comportamental. 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 modalităţ ile in care
sistemul poate fi folosit.
Cazurile de utilizare : -
sunt unităţi de sine stătătoare, bine delimitatate (începutul şi sfârşitul unui caz de utilizare sunt
-
cuprinse în acesta).
-
trebuie să fie iniţiate de un
actor şi terminarea lor să fie 'văzută' de un actor 4
trebuie să îndeplinească anumite scopuri de logică a problemei (dacă nu se poate găsi un astfel de
-
obiectiv atunci cazul de utilizare trebuie regândit) trebuie să lase sistemul într -o stare stabilă (nu poate fi îndeplinit doar pe jumătate)
-
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 aplicaţie. 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 Precondiţii Postcondiţii Calea principală ( sau BCE - Basic Course of Events) Căi alternative ( sau ACE - Alternate Course of Events) Căi de excepţie
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
Relaţii între cazuri de utilizare (figura 4): - relatia de utilizare: are loc intre un caz de utilizare si oricare alt caz de utilizare ce utilizează
funcţionalitatea acestuia. Se reprezintă grafic printr -o linie având la capătul 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). 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 <>.
Figura 4. Reprezentarea grafica a relatiilor de extindere si utilizare
intre cazuri de utilizare
Relaţii între actori (figura 5): - relaţia de generalizare: semnifică f aptul ca un actor modalităţile prin care interacţionează un altul.
poate interacţiona cu sistemul in toate
Se reprezintă ca o relaţie de extindere intre două cazuri de
utilizare fară a avea stereotip. - relatia de dependenţă: semnifică faptul că, pentru
a interacţiona cu sistemul informatic prin
intermediul unui caz de utilizare, un actor dep inde de alt actor. Se reprezintă printr -o linie frânta având la un capăt 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.
6
3. Diagrama de interacţiune (de secvenţă şi de colaborare)
Diagrama de cazuri de utilizare reprezintă imaginea sistemului privit din exterior. Funcţionalitatea 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.
Scenarii le pot
fi privite ca instanţe (sau realizări) ale cazurilor de utilizare: ele descriu o secvenţă de acţiuni concrete care pot avea loc la un moment dat în sistem.Determinarea scenariilor are rolul de a ajuta: - înţelegerea funcţionalităţii cazurilor de utilizare, - specificarea modului în care responsabilităţile unui caz de
utilizare sunt distribuite obiectelor
şi claselor din sistem, - identificarea obiectelor şi claselor, - identificarea interacţiunilor între obiecte, necesare pentru realizarea unei părţi funcţionale
concrete descrisă de un caz de utilizare. - comunicarea pe baza specificaţiilor proiectului
Fiecare caz de utilizare este o reţea de scenarii conţinând un scenariu principal şi mai multe scenarii secundare. Iniţial se definesc scenariile primare pentru toate cazurile de utilizare. Scenariile alternative (secundare) se definesc până în momentul în care se observă că fiecare nou scenariu repetă o serie de paşi identificaţi
î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), interacţiune. colaborare.
scenariile se descriu prin intermediul aşa -numitelor diagrame de
În UML avem două tipuri de diagrame de interacţiune: diagramele de secvenţă şi de Fiecare dintre aceste diagrame reprezintă o vedere grafică diferită a unui scenariu.
Diagrame de secvenţă
Diagramele de secvenţă prezintă interacţiunile care au loc între diverse obiecte ale unui sistem, ordonate cronologic. Ele determină obiectele şi clasele implicate într -un scenariu şi secvenţele de mesaje transmise între obiecte necesare îndeplinirii funcţionalităţii 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. Prezenţa numelui obiectului sau al clasei este opţională, însă nu pot lipsi ambele în acelaşi timp. Atunci când numele obiectului lipseşte, reprezentarea grafică simbolizează un obiect anonim (utilizat în reprezentarea opricărui obiect al unei clase).
7
Fiecărui obiect îi corespunde o linie a timpului, reprezentată printr -o linie punctată sub reprezentarea obiectului. Mesajele transmise între obiecte sunt reprezentate prin săgeţi (de la obiectul client, sursă spre obiectul server, destinaţie, receptor) etichetate cu numele mesajului (figura 1).
Figura 6.
În cadrul unei diagrame de secvenţă pot fi implicaţi şi actori (figura 8).
Figura 7.
Figura 8 prezintă scenariul de adăugare a unui nou curs opţional î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 funcţionalităţii claselor de interfaţă, fără a sugera modul de implementare a acestora. Observaţii: 'Cât 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 conţin logică condiţională?' În
cazul în care logica este simplă, se
construieşte o diagramă de secvenţă simplă, cu puţine mesaje, la care se adaugă comentarii de descriere a condiţiilor 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 condiţională implică un set numeros de mesaje, atunci se va realiza câte 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ă interacţiunile dintre obiecte organizate relativ la acestea şi a l egăturilor dintre ele. Diagramele de colaborare conţin (figura 10): -
obiecte, în reprezentarea lor grafică sub formă de dreptunghiuri
-
legături între obiecte, reprezentate grafic prin linii de conectare
-
mesaje, reprezentate ca etichete ale legăturilor, şi care conţin o săgeată î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 operaţiilor acestora şi a relaţiilor dintre clase. Construcţia 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 determinării claselor ce
modelează soluţia unei probleme informatice este aceea de a extrage substantivele esenţiale din documentul de specificaţie. O metodă mult mai rapidă este accea de a extrage toate substantivele care apar în diagrama de cazuri de utilizare (atât în denumirile actorilor cât şi a cazurilor de utilizare). După dobândirea unei anumite experienţe î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 iniţială de substantive se vor aplica o serie de 7 reguli de filtrare. Se vor elimina toate clasele-candidat care au una dintre următoarele 1.
caracteristici:
Este redundantă: două substantive care reprezintă acelasi lucru sunt
redundante (ex. maşină
– 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 construcţie 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:
- Claseentităţi (sau clase domeniu) – reprezintă nucleul unei aplicaţii, reţin informaţii legate de entitătile
persistente şi capturează serviciile ce conduc majoritatea interacţiunilor în aplicaţie. De obicei clasele entitate trebuie să:
înmagazineze şi redea valori de atribute,
creeze şi sa ştearga entităţi,
furnizeze un comportament dependent de modificarea starii entitatii.
10
-Clase de interfaţă – reprezinta graniţa dintre actorii
care doresc să interacţioneze cu aplicaţia şi clasele
entitate. Majoritatea sunt componente ale interfeţei utilizator (fiecare cutie de dialog este o clasă de interfaţă), modeleaza comunicarea cu alte aplicaţii sau reprezinta clase wrapper peste anumite componente soft. Se determina studiind:
modul in care doresc actorii să ceeaze entităţi,
interfaţa între aplicaţie şi alte sisteme,
modalitatea de vizualizare a informaţiilor (rapoarte).
-Clase de control (controller) – coordonează activitatea controller pentru fiecare caz de utilizare.
în interiorul aplicaţiei. Se crează câte o clasă
Pot juca unul din următoarele roluri:
modelarea unui comportament tranzacţional,
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
Relaţii între clase - asigură posibilitatea colaborării î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 conţine 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'.
legătură (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 proprietaţilor, operaţiilor si relatiilor între două clase (rafinarea,
specializare a clasei). Clasa generala poarta numele de superclasă , iar clasa specializata de numeste subclasă.
Generalizarea apare atunci când 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 când o clasă utilizează o altă clasă ca argument pentru una din operaţiile sale).
Figura 13. Reprezentarea grafica a relatiei de dependenta in UML
Reprezentarea si descrierea relatiilor in diagrama claselor
Notaţie
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 operaţiile specifice clasei.
Moştenire
Moştenirea este o relaţie care indică faptul că o clasă moşteneşte caracteristicile unei clase părinte. Sensul săgeţii indică sensul în care se poate spune despre clasa copil că este o<-i>, sau este de tipul<-i> clasă părinte.
Asocierea este o relaţie generică între două clase. Aceste relaţii Asociere
Anexa 1
pot fi de tipurile pot defini şi regulile numerice de asociere (unu la unu, unu la mai mulţi, mai mulţi la mai mulţi).
Dependenţă
Atunci când o clasă depinde de o altă clasă, în sensul că utilizează acea clasă ca şi atribut al său, se foloseşte relaţia de dependenţă.
Agregare
Agregarea indică o relaţie de tip întreg -parte (se poate spune despre clasa părinte că are clase de tip copil). În această relaţie, clasa copil poate exista şi fără clasa părinte.
Compoziţie
Această relaţie derivă din agregare dar se utilizează atunci când o clasă copil nu poate exista decât în cazul existenţei clasei părinte.
13
5. Diagrama de stare
Cazurile de utilizare şi scenariile reprezintă modalităţi de descriere a comportamentului sistemelor informatice (văzut ca interacţiuni între obiecte).
În anumite cazuri însă este necesară studierea
comportamentului în interiorul unui obiect. UML furnizează diagramele de tranziţie a stărilor şi diagramele de activităţi pentru modelarea comportamentului obiectelor. În UML diagramele de tranzitie a stărilor sunt utilizate în descrierea comportamentului obiectelor aparţinând unui clase. O stare (concretă)
este caracterizată de valorile proprietăţilor unui obiect şi de mulţimea mesajelor care
pot fi acceptate de către acest obiect la un moment dat. O stare conţine de scrierea unui invariant de stare (condiţie logică adevărată pentru toate obiectele care se află în starea respectivă), şi a trei proceduri speciale: entry, exit şi do.
Aceste proceduri descriu secvenţele de acţiuni care vor fi executate în
momentul în care un obiect intră ( entry), părăseşte (exit ) sau se află (do) în starea respectivă. O stare se reprezintă grafic prin intermediul unui dreptunghi cu colţurile rotunjite, afişând în partea superioară un nume de stare.
În partea inferioară a dreptunghiului opţional poate exista un compartiment care conţine
expresiile ce definesc invariantul de stare şi cele trei proceduri speciale. O tranziţie
exprimă o situaţie în care un obiect poate trece dintr -o stare în alta. Tranziţiile se reprezintă
grafic prin intermediul unor arce de cerc, linii simple sau linii poligonale orientate şi (opţional) etichetate
care unesc două stări, numite stare sursă, respectiv destinaţie. Eticheta unei tranziţii este formată dintr -o signatură de mesaj,
o condiţie (expresie logică) şi o secvenţă de activităţi care au loc în momentul
declanşarii tranziţie. Pentru un obiect oarecare o tranziţie este declanşată atunci când obiectul se află în starea sursă a acesteia, execută operaţia corespunzătoare mesajului şi este îndeplinită condiţia specificată în etichetă. Hărţile de stări permit reprezentarea ierarhică a stărilor unui obiect prin intermediul stărilor compuse (întâlnite şi sub denumirea de XOR -stări, stări abstracte sau super -stări). Stările compuse conţin un număr finit de stări simple sau compuse. Un obiect aflat într -o stare compusă se va afla în una şi numai una din sub-stările acesteia. Stările compuse se reprezintă grafic la fel ca stările simple, la care se adaugă
un compartiment special, localizat între numele stării şi compartimentul destinat afişării invarianţilor de stare şi a procedurilor speciale. În cadrul acestui compartiment sunt reprezentate grafic toate sub -stările corespunzătoare.
14
Figura 14. Etichetarea tranziţiilor în hărţile de stări UML
Hărţile de stări permit modelarea de comportamente paralele ale unui obiect prin intermediul stărilor ortogonale (denumite şi AND-stări sau stări concurente).
Stările ortogonale sunt formate din mai multe
componente ortogonale , fiecare dintre acestea conţinând diverse sub -stări.
Un obiect aflat într -o stare
ortogonală se va afla de fapt în câte o stare corespunzătoare fiecărei componente ortogonale a acesteia. Reprezentarea grafică a stărilor ortogonale este asemănătoare reprezentării stărilor compuse, componentele ortogonale ale acestora fiind delimitate prin linii punctate verticale.
Figura 15. Principalele notaţii ale hărţilor de stări UML
De asemenea, hărţile de stări introduc o serie de stări speciale, numite pseudo- stări. Pseudo-stările sunt stări intermediare care permit conectarea mai multor tranziţii în scopul descrierii unor situaţ ii complexe de modificare a stării concrete a unui obiect. Cele mai importante pseudo-stări definite în UML sunt: -
starea iniţială -
indică sub-starea implicită în care intră un obiect în cazul declanşării unei
tranziţii a cărei stare destinaţie este o stare compusă. Se reprezintă grafic sub forma unui cerc plin.
15
-
starea finală - indică părăsirea contextului unei stări compuse.
În cazul în care starea finală
aparţine stării compuse de la cel mai înalt nivel al ierarhiei de stări (este rădăcina ierarhiei de stări) intrarea o tranziţie spre această stare semnifică distrugerea obiectului. -
starea istoric -
este utilizată atunci când sub -starea iniţială a unei stări compuse nu este
fixată decât pentru prima tranziţie spre această stare compusă, ea fiind dată mai apoi de ultima sub -stare activă. În figura 16 o primă tranziţie spre starea Pornita implică activarea sub -stării Normal , următoarele tranziţii activând sub-starea ( Normal sau Marsarier ) activă în momentul ultimei părăsiri a stării Pornita. Pseudostările istoric au două variante: superficiale şi profunde - pseudostările istoric profunde activează recursiv ultima substare activată a ultimei stări compuse active. Alături de pseudostările de ieşire, de intrare şi istoric, UML mai introduce alte trei pseudostări fără semnificaţie semantică, având ca rol creşterea lizibilitaţii diagramei: -
stările ramificaţie (branch - pentru reprezentarea a două sau mai multe tranziţii dintr -o stare sursă
comună,
declanşate
de
- fork şi join (pentru tranziţii în şi din
acelaşi
eveniment,
dar
cu
gărzi
diferite),
stări aflate în componente ortogonale) - figura 3.
Figura 16. Pseudostările ramificaţie (a), fork (b) şi join (c)
O data cu introducerea starilor compuse se introduce si terminare).
noţiunea de tranziţie de completare (sau
O astfel de tranziţie este neetichetată cu un nume de eveniment (eventual ea poate avea
asociata o conditie). Dacă în urma tratării unui anumit eveniment un obiect se află într -o configuraţie de stări ce permite declanşarea de tranziţii de terminare atunci spunem că obiectul respectiv a atins o configuraţie instabilă.
16
Figura 17. Exemplu de utilizare a unei tranziţii de terminare
Tratarea următorului eveniment se va realiza în acest caz doar după efectuarea unui număr corespunzător de paşi, până când se atinge o configuraţie stabilă (în exemplul din figura 4 obiectul va atinge o configuraţie instabilă imediat după tratarea evenimentului e; în această fază se realizează un nou pas de trecere a obiectului în starea C ). În cazul unei proiectări incorecte se poate ajunge în situaţia în care nu se atinge niciodată o configuraţie stabilă.
Figura 18. Activarea stărilor în cazul unei tranziţii (e1) în cadrul unei stări
compuse (B)
a) intr are 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 stării 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 , F lux ur il e de contr ol si : F lu xur il e obiect reprezinta procesul prin care un element al sistemului informatic isi indeplineste Activitatea 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 la
intrarea iesirea
intr-o
activitate
dintr-o
(aceste
activitate
actiuni (actiuni
sunt
precedate
precedate
de de
cuvantul
"entry")
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
indica ordinea in care se realizeaza activitatile. Un flux de control este reprezentat F lu xur il e de contr ol 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 ver ticala, 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ă dependenţele 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 compone ntă reprezintă o parte distinctă, realocabilă,
a implementării unui sistem. Instanţa unei
componente este o unitatea de implementare în execuţie şi poate fi utilizată pentru reprezentarea unităţilor de implementare care au o identitate în momentul execuţ iei. 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 (opţional) 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 instanţei 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ă relaţii de dependenţă sau de compunere (componente incluse fizic în alte compon ente). 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 conţine tipuri de componente poate fi utilizată, spre exemplu, pentru reprezentarea de dependenţe statice, cum este dependenţa 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 (<>)
- librarii cu legare dinamica (<>)
- subprograme (<>)
- procese ( <> )
- pachete (<>)
- executabile ( <>) 23
8. Diagrama de desfăşurare Diagramele de
desfăşurare prezintă configuraţia elementelor de procesare din timpul execuţiei şi
componentele, procesele şi obiectele care le conţin. Fiecare model al unui sistem informatic are asociata o singura diagrama de exploatare. Instanţele componentelor soft reprezintă manifestări a unor unităţi de cod în cadrul execuţiei. Componentele care nu există ca entităţi de execuţie nu apar în aceste diagrame, ci doar în diagramele de componente. O diagramă de desfăşurare este un graf de noduri conectate prin asocieri de comunicare. Nodurile pot conţine instanţe ale componentelor (componenta există sau se execută pe nodul res pectiv). Componentele pot conţine obiecte (acestea sunt localizate în componente). Componentele sunt conectate cu alte componente sau interfeţele acestora prin intermediul unor relaţii de dependenţă (săgeţi întrerupte) ceea ce reprezintă faptul că o componentă foloseşte serviciile altei componente. Pot fi utilizate stereotipuri pentru a preciza în detaliu tipul dependenţei dintre componente. Un nod este o entitate fizică ce reprezintă o resursă de procesare, având o memorie şi anumite capabilităţi 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 (opţional) un nume de instanţă şi un nume de tip (nume instanţă : nume tip).
O asociere între două noduri indică existenţa unei căi de comunicare între noduri. Asocierea poate
avea un stereotip care să indice tipul de comunicare (tipul de canal, reţea). Diagramele de
desfăşurare pot fi uti lizate pentru reprezentarea componentelor ce pot aparţine anumitor
noduri. Această relaţie se reprezintă grafic prin intermediul unei linii întrerupte între un nod şi o componentă, având stereotipul <> sau prin ‘încuibărirea’ grafică a simbolului componentei în cadrul simbolului ce reprezintă nodul (figura 6).
Figura 28. Diagrama de desfăşurare pentru o aplicatie
de gestiune a biletelor de calatorie cu avionul
Migrarea instanţelor de componente dintr -un nod în altul, sau migrarea obiectelor de la o componentă la alta poate fi implementată grafic utilizând stereotipul <> ataşat relaţiei de dependenţă. În această situaţie instanţa componentei/obiectul vor aparţine unei instanţe a unui nod/unei instanţe de componentă doar o perioadă de timp din ciclul lor de viaţă. Instrumentul Rational Rose contine un editor de diagrame de
desfăşurare particulare. Aceste diagrame de
desfăşurare 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) - f igura 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) i ntre doua dispozitive sau procesoare.
Figura 30. Diagrama de desfăşurare a unui sistem informatic oarecare
25
9. Modelarea Serverului FTP.
File Transfer Protocol ( FTP ) este un protocol standard de rețea utilizat pentru a tr ansfera fișiere de la o gazdă la o altă gazdă printr -o rețea 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ă conținutul , 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 aplicații client FTP au fost cereri de linie de comandă dezvoltate îna inte de sistemul de operare a unei interfețe 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 aplicații de
productivitate , cum ar fi editori de pagini web . Istoria aparitiei a fost elaborarea caietului de sarcini inițial pentru File Transfer Protocol a fost scris de A bhay Bhushan și publicat ca RFC 114 la 16 aprilie 1971. Până î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 definește un nou tip de modul pasiv. FTP poate rula în mod activ sau pasiv , care determină modul în care se stabilește conexiunea de date.[5 ] În modul activ , clientul creează o conexiune de control TCP . În situațiile î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 primește o adresă IP a serverului și numărul portului de server de la serverul , [ 5 ] [ 6 ] , care folosește apoi clientul pentru a deschide o conexiune de date de la un port client arbitrar la adresa IP a serverului și
numărul portului serverului primit . [ 7 ] Ambele moduri au fost actualizate în septembrie 1998 pentru a sprijini IPv6 . Alte modificări 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 opțional . De exemplu, " 200 " ( sau " 200 OK " ), înseamnă că ultima comanda a f ost de succes .
26
9.1.
Diagrama Use-Case
uc copierea informatiei din mail cu a jutorul serv erului FTP
Deschiderea client browser
Client
Serverul web «include»
Copiere fisierilor din mail
«include»
«include» «include»
securitatea informatiei TSG
Logare geosclml Cerere de copiere CSV
Accesarea mailului
«include»
Gestionarea bazei de date Serv erul FTp
Figura 31- Copierea informației din mail
cu ajutorul serverului FTP
În diagrama dată se copie informția 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 serverul 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 tran sferul de date , stergerea unui fisier,coipere ,descărcarea fișierilor in server,din server. 27
uc transferul informatiei din se rv erul local in serv erul FTP
Server local
Client Conectarea la mailul
Serv er FTP
dat
«include»
Transferul informatiei
Figura 33 – Diagrama Use-Case a transferul informației din serverul local in serverul FTP
În diagrama dată are loc transferul de date din serverul local in serve rul 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 sis temul 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 înregistrării unui clinet in sistemul FTP. Clientul deschide browser -ul procesul este preluat de client server si el transmite cerere de indentificare a clientului cu aj utorul 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 interacţiune (de Secvenţă şi de Colaborare) Diagrama de Secvenţă
sd copierea informatiei din mail cu aj utorul FTP se rve r Client Browser
Serverul Web
Baze de Date
Serverul FTP
Client
deschidem browser()
accesare mail() acces confirmat()
selecteaza m esajul ()
selecteaza mesajul()
a prelua mesajul()
mesaj g asit()
descarcarea mesajulu i()
prelucrarea fisierului() incepe descarcarea ()
mesaj descarcat()
Figura 35 -
Diagrama de secvenţă a Copierea informației din email cu ajutorul FTp server
În diagrama dată se copie informția 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 ser verul 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 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 36 – Diagrama de secvenţă a inregistrarii in sistemul FTP
În diagrama data are loc descrierea înregistrării unui clinet in sistemul FTP. Clientul deschide browser -ul procesul este preluat de client server si el transmite cerere de indentificare a cli entului 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 serverul FTP Client FTP
Serverul FTP
Client
logare()
confirmare()
verificare() acceptat()
acceptat()
inca rcare fisier()
incarcare fi sier()
incarcat()
incarcat()
descarcare fisier() descarcare fisier()
cautare fi sier() fisier ga sit()
descarca fi sierul ()
Figura 37 - Diagrama de secvenţă
corespunzatoare lucrului cu fișierele in serverul FTP
În diagrama dată are loc transferul de date ,coipere ,descărcarea fișierilor 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 fi sierul de transfer()
fisier i ncarcat()
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 corespunzătoare înregistrării 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 corespunzătoare copierii 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
informației din email cu ajutorul FTP
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 corespunzătoare lucru lui cu fisierele in serverul FTP
În diagrama dată are loc transferul de date ,coipere ,descărcarea fișierilor in server ,din server prin intermediul conectarii la aplicatia serverului.
analysis transferul informatiei din se rv er local in serv erul FTP
Dispozitiv de transfer
Internet
Trimite cererea de transfer
Incarcarea fisierelor de transfer
Serverul local de fisiere
Serv erul FTP
Figura 42 – Diagrama de colaborare tip de specificare corespunzătoare 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 P rocess M odel
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() : voi d
Dispozitiv ul DNS + +
autenti fica IP() : void translatea za() : void
Figura 43 – Diagrama claselor corespunzătoare
înregistrării in serverul FTP
În diagrama data are loc descrierea înregistrării unui c linet 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 browse r
-
IP: int nr_telefon: int nume: int prenume: int
+ +
acceseaza() : voi d selecteaza() : void
-
interfata: int
+
afiseaza() : void
server w eb
Serv er FTP
-
date: int informatii: int
+ + +
accesare() : voi d conect are() : void transmite () : void
baze de date
-
aplicatii: int
-
tabel de alocare: int
+ + + +
autenti ficare() : void executare() : void transfera() : voi d verificare() : void
+ + +
gestioneaza date() : void pastreaza date() : void verifica date() : void
Figura 44 – Diagrama claselor corespunzătoare copierii
informației din email cu ajutorul FTp server
În diagrama dată se copie informția 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 modifi ca() : void sele cteaza() : void
browser
-
interfata: int
+
afi seaza() : void
Client FTP
+ + +
autentifica() : void citeste date() : void indenti fica() : void
Serv erul FTP
Figura 45 – Diagrama de clase tip de
-
apli catii: int porturi: int volum de date: int
+ + +
autentifi ca() : void executa() : void transfera() : voi d
specificare corespunzătoare lucrului cu fisierele in serverul FTP
În diagrama dată are loc transferul de date ,coipere ,descărcarea fișierilor in server ,din server prin intermediul conectarii la aplicatia serverului. class Class Model
-
ID: int nr_telefon: int nume: int prenume: int
+ + +
acceseaza() : void modi fica() : void sel ecteaza() : void
web server
dispozitiv ul de transfer
client
+
transfera inf o() : void
-
pagini de informatii: int
+ + +
autentifi ca() : void conectea za() : void transmi te() : void
serv erul FTP
-
aplicatii: int porturi: int volum de date: int
+ + +
autentifi care() : void executa() : void transfera() : void
Figura 46 – Diagrama de clasa
serv erul local de fisiere
+ + +
descarca date() : void incarca date() : void transfera() : void
corespunzătoare 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 c onexiune
selectarea mesajului
[date prezente]
verificarea conexiunii la internet
[mesajul nu exista in baza de date]
nu poate fi descarcat mesaj descarcat
Final
Final Final
Figura 48 -
Diagrama de stare corespunzătoare copierii informației din email cu ajutorul FTp server
În diagrama dată se copie informția din email cu ajutorul serverului FTP. Clientul des chide 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 li ber]
eroare la conexiune autentificare la server
[date introduse corect]
[nr<=3]
[date i ncorecte]
incercare noua logat
incercare noua
[nr>3]
incercare noua dupa ora 00:00
Final
Final
Figura 49 - Diagrama de stare
Diagrama de stare corespunzătoare înregistrării in serverul FTP
În diagrama data are loc descrierea înregistrării unui clinet in sistemul FTP. Clientul deschide browser -ul procesul este preluat de client server si el transmite cerere de indentific are 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 acces eaza
clientul acceseaza
aplicatia client FTP
[nr<=3]
autentificare [parola si logi n corect]
logat
[logi n sau parola i ncorecta]
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 corespunzătoare lucrului cu fisierele in serverul FTP
În diagrama dată are loc transferul de date ,coipere ,descărcarea fișierilor 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 corespunzătoare 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 activităţi
analysis clietul acceseaza
clientul deschide
accesarea unei pagini w eb
conectarea la serve r
[server supraincarcat]
[server li ber]
eroare la conexiune autentificare la server 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 corespunzătoare
înregistrării in serverul FTP
În diagrama data are loc descrierea înregistrării 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 serverul FTP
Final
Figura 53 – Diagrama de activitate corespunzătoare lucrului cu fisierele in serverul FTP
În diagrama dată are loc transferul de date ,coipere ,descărcarea fișierilor in server ,din server prin intermediul conectarii la aplicatia serverului.
42
analysis Business Process Model client
deschide browser
internet
mail
conexiune la internet
[exista conexiune] [nu e conex]
accesarea emailului
eroare
selectarea mesaj ului
descarcare mesaj
Acti vityFina l
Figura 54 – Diagrama de activitate corespunzătoare copierii
informației din email cu ajutorul FTp server
În diagrama dată se copie informția 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
Acti vity Ini tia l
conectare la protocolul FTP
conectarea la internet
conectat [exista conexiun e]
[nu este conexiune] eroare
introducerea datelor eroare
[date i ntroduse incorect]
[date corecte] executare transfer
logat
transferat
Acti vityFi na l
Figura 55 – Diagrama de activitate corespunzătoare transferului de date din serverul local
in serverul FTP
În diagrama dată are loc transferul de date din serverul local i n 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
web server
client 2
client FTP
«device»
FTP server
comunication device
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
