Documente Academic
Documente Profesional
Documente Cultură
PROIECT DE CURS
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 --------------------------------------------------------------------------- 24
9. Modelarea Serverului FTP--------------------------------------------------------------------------26
9.1. Diagrama Use-Case ---------------------------------------------------------------------------- 27
9.2. Diagrama 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, pentru a obtine o atenț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 limbajul
universal standard pentru dezvoltatorii software din toata lumea. UML este succesorul propriu-zis al celor
mai bune trei limbaje de modelare anterioare orientate pe obiecte (Booch, OMT, and OOSE). Uml se
constituie din unirea acestor limbaje de modelare si în plus detine o expresivitate care ajută la rezolvarea
problemelor de modelare pe care vechile limbaje nu o aveau.
Limbajul de modelare modificat (UML - The Unified Modeling Language) ofera arhitecturi de
sisteme ce 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. Modelarea î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 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 notaţiile UML care vor fi grupate dupa diagramele 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).
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).
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. Scenariile 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), scenariile se descriu prin intermediul aşa-numitelor diagrame de
interacţiune. În UML avem două tipuri de diagrame de interacţiune: 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ă 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 legă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 caracteristici:
1. 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 în interiorul aplicaţiei. Se crează câte o clasă
controller pentru fiecare caz de utilizare. 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ţă.
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.
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 descrierea 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.
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 acelaşi eveniment, dar cu gărzi diferite),
- fork şi join (pentru tranziţii în şi din stări aflate în componente ortogonale) - figura 3.
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) 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 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, Fluxurile de control si
Fluxurile obiect:
Activitatea reprezinta procesul prin care un element al sistemului informatic isi indeplineste
responsabilitatile pe care le are. Fiecare astfel de element are responsabilitatea de a reactiona la stimuli
externi, la mesajele receptionate, si aceste responsabilitati pot fi descrise prin intermediul activitatilor.
O activitate poate fi detaliata in actiuni. Aceste actiuni pot fi executate in trei cazuri distincte:
- la intrarea intr-o activitate (aceste actiuni sunt precedate de cuvantul "entry")
- la iesirea dintr-o activitate (actiuni precedate de cuvantul "exit")
- dupa intrarea intr-o activitate si care continua pana cand activitatea se termina (actiuni marcate
prin cuvantul "do").
Activitatile se reprezinta grafic prin intermediul unui dreptunghi rotunjit, avand in centru
denumirea acestora (figura 1).
18
Fluxurile de control indica ordinea in care se realizeaza activitatile. Un flux de control este reprezentat
printr-o sageata ce leaga doua activitati (numite activitate sursa si activitate destinatie) si semnifica
inceperea realizarii activitatii destinatie imediat dupa finalizarea activitatii sursa. Fluxurile de control mai
poarta numele de tranzitii implicite sau automate deoarece nu sunt etichetate si sunt "activate" imediat
dupa terminarea activitatii sursa.
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.
21
activitatii Monitorizarea Cererilor de Listare. Odata ce ambele activitati s-au terminat, un contabil poate
alege listarea unor alte rapoarte.
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 componentă 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.
22
Diagrama de componente este un graf de componente între care există relaţii 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 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 .
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) - figura 7.
In aceste diagrame, procesele reprezintă fire de excutiedistince (ex. programul principal, sau obiecte
active).
25
9. Modelarea Serverului FTP.
File Transfer Protocol ( FTP ) este un protocol standard de rețea utilizat pentru a transfera 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 înainte 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
Abhay 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 fost de succes .
26
9.1. Diagrama Use-Case
uc copierea informatiei din mail cu aj utorul serv erului FTP
Deschiderea client
Client brow ser
Serv erul w eb
«include»
Accesarea mailului
«include»
Gestionarea bazei de
date
Serv erul FTp
Logare Autorizare
«extend»
«include»
Incarca fisiere
«include»
«include»
Copiere fisier
Sterge fisiere
FTP serv er
27
uc transferul informatiei din serv erul local in serv erul FTP
Serv er 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 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.
logare
inregistrare
«include» «include»
«include»
preluarea IP DNS
28
9.2. Diagrama de interacţiune (de Secvenţă şi de Colaborare)
Diagrama de Secvenţă
sd copierea informatiei din mail cu ajutorul FTP serv er
Client
deschidem browser()
accesare
mail()
acces confirmat()
selecteaza mesajul()
selecteaza mesajul()
a prelua mesajul()
mesaj gasit()
descarcarea mesajului()
prelucrarea fisierului()
incepe descarcarea ()
mesaj descarcat()
Figura 35 - Diagrama de secvenţă a Copierea 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ă.
29
sd inregistrarea in sistemul serv erul FTP
Client
deschidem browser()
prelucrarea()
IP indentificat()
conectat()
date introduse()
date acceptate()
verificare()
bine ati venit logat()
logare cu succes()
30
sd lucru cu fisierele in serv erul FTP
Client
logare()
confirmare()
verificare()
acceptat()
acceptat()
incarcare fisier()
incarcare fisier()
incarcat()
incarcat()
descarcare
fisier()
descarcare fisier()
cautare fisier()
fisier gasit()
descarca fisierul()
31
sd transferul de date din serv erul local in serv erul FTP
executa()
control la
conectare()
conectat()
introduceti
login,parola()
logare()
client()
parola()
verificare()
validare conectat()
conectat()
conectat()
doresc sa transfer()
trimiterea cererii()
transfer acceptat()
fisier incarcat()
transfer cu succes()
Figura 38– Diagrama de secventa corespunzatoare transferului de date din serverul local in serveul FTP
În diagrama dată are loc transferul de date din serverul local in serverul FTP. Clientul transfară anumite
date prin intermediul internetului, internetul conecteaza clientul cu serverul local si mai apoi clinetul se
loghiaza la serverul local și mai apoi are loc transferul dat.
32
Diagrama de colaborare
Figura 40 – Diagrama de colaborare corespunzătoare copierii informației din email cu ajutorul FTP
server
1:Clientul deschide browser 7:Treluarea mesajului din baza de date
2:Accesarea mailului 8:Mesaj preluat
3:Raspuns la accesare 9: Descarcarea mesajului
4:Raspuns acceptat 10:Prelucrarea mesajului
5:Selecteaza mesajul care doreste sa descarce 11:Transmite raspuns la descarcare
6:Transmiterea mesajului de transfer 12: Începe descarcarea
33
analysis Business Process Model
Descarcare
Incarcare fisiere
fisiere
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 Process Model
Dispozitiv ul DNS
Î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ă.
client
client brow ser
- IP: int
- nr_telefon: int - interfata: int
- nume: int
+ afiseaza() : void serv er w eb
- prenume: int
- date: int
+ acceseaza() : void - informatii: int
+ selecteaza() : void
+ accesare() : void
+ conectare() : void
+ transmite() : 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
+ autentifica() : void
+ citeste date() : void
+ indentifica() : void
- aplicatii: int
- porturi: int
- volum de date: int
+ autentifica() : void
+ executa() : void
+ transfera() : void
Figura 45 – Diagrama de clase tip de 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.
+ acceseaza() : void
+ modifica() : void
+ selecteaza() : void
- aplicatii: int
- porturi: int serv erul local de fisiere
- volum de date: int
+ descarca date() : void
+ autentificare() : void + incarca date() : void
+ executa() : void + transfera() : void
+ transfera() : void
Figura 46 – Diagrama de clasa 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
clientul
acceseaza
unei pagini w eb
[exista conexiune]
[nu exista conexiune la internet]
accesarea mailului
eroare la conexiune
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 deschide browser-ul
accesează mail-ul si selecteaza mesajul prin intermediul serverului web deschide mesajul din baza de date
prin intermediul caruia mesajul sa gasit si din serverul FTP se descarca mesajul care are informatia dorită.
37
analysis clietul acceseaza
clientul
deschide
conectarea la serv er
[server
[server liber]
supraincarcat]
eroare la conexiune
autentificare la serv er [nr<=3]
incercare noua
logat incercare noua
[nr>3]
Final
Final
38
analysis clietul acceseaza
clientul
acceseaza
aplicatia client FTP
[nr<=3]
autentificare
logat
incercati din nou
[nr>3]
Final
Final
39
analysis clietul acceseaza
Initial
conectarea la
protocolul de transfer
FTP
verificarea conexiunii
conectare la internet
introducerea datelor de
autentificare Final
eroare la logare
logat
[nr.>3] [nr.<=3]
introducerea emailul
Final
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
conectarea la serv er
eroare la conexiune
autentificare la serv er
incercare noua
[dae introduse incorect]
[date introduse corect]
incercare noua
logat
[nr>3] [nr<=3]
incercare noua dupa
ora 00:00
Final
41
analysis clietul acceseaza
clientul
acceseaza
autentificare
Final
42
analysis Business Process Model
[exista conexiune]
[nu e conex]
accesarea emailului
eroare
descarcare mesaj
ActivityFinal
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
ActivityInitial
conectare la protocolul
conectarea la internet
FTP
conectat
[exista conexiune]
eroare
introducerea datelor
eroare
[date corecte]
ActivityFinal
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 in serverul FTP. Clientul transfară anumite
date prin intermediul internetului, internetul conecteaza clientul cu serverul local si mai apoi clinetul se
loghiaza la serverul local și mai apoi are loc transferul dat.
44
9.6. Diagrama componentelor
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).
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
client 1
w eb serv er
managing users
client 3
46
10. Concluzie
În urma efectuării acestei lucrări am ajuns la concluzia că:
Proiectarea – nu este desenarea diagramelor, diagramele pur şi simplu reflectă rezultatele
proiectării.
La proiectarea unui sistem complex e important de a-l studia din diferite unghiuri de vedere –
atât din punct de vedere al structurii logice / fizice, cât şi al semanticii statice / dinamice.
Sistemul de notări al proiectării orientate pe obiecte include 7 diagrame
Diagrama claselor arată ce clase există şi legătura 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 stărilor şi activităţilor prezintă : 1. spaţiul stărilor exemplarelor clasei date; 2.
evenimentele care provoacă tranziţia dintr-o stare în alta, 3. acţiunile care au loc la schimbarea stării.
Diagrama interacţiunilor permite urmărirea î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
47