Cuprins:

Introducere n UML.............................................................................3
1.1.Aparitie si evolutie..........................................................................3
1.2. Principalele pri ale UML..............................................................4
1.2.1. View-uri..................................................................................4
1.2.2. Diagrame................................................................................6

2.Mersul lucrrii.................................................................................12
2.1. Elaborarea diagramelor use case..................................................12
2.2.Elaborarea diagramelor de segven..............................................14
2.3.Elaborarea diagramelor de colaborare...........................................16
2.4.Elaborarea diagramelor de clase....................................................18
2.5.Elaborarea diagramelor de stare....................................................22
2.6. Elaborarea diagramelor de activiti.............................................25
2.7.Elaborarea diagramelor de componente i de desfurare

.........27

Concluzie ...........................................................................................29
Bibliografie.........................................................................................30

Introducere n UML

1.1. Aparitie si evolutie

UML este un limbaj vizual de modelare, el nu este nc un limbaj vizual de programare, deoarece
nu dispune de ntreg sprijinul semantic i vizual pentru a nlocui limbajele de programare.
Limbajul este destinat vizualizrii, specificrii, construirii i documentrii sistemelor de aplicaii,
dar are limitri n ceea ce privete generarea codului. UML reunete cele mai bune tehnici i
practici din domeniul ingineriei programrii, care i-au dovedit eficiena n construirea
sistemelor complexe.
Cteva date semnificative referitoare la apariie i evoluie:
n octombrie 1994, Grady Booch lider stiinific la Rational Corporation, autor al metodei
ce-i poart numele i a unor cri de referint n domeniu face echip cu James
Rumbaugh, autorul principal al metodei OMT, pe care-l determin s-si prseasc (cel
puin temporar) vechiul loc de munc (General Electric) i s treac la firma Rational.
Dup un an de activitate Booch i Rumbaugh, prezint n octombrie 1995 cu ocazia
conferinei OOPSLA, caracteristicile de baz ale unei noi metode de analiz i proiectare,
rezultat prin unificarea Metodei lui Booch (OOD) cu OMT, metod denumit Metoda
unificat (Unified Method). Prima documentaie a metodei menionat anterior a fost
fcut public n decembrie 1995, avnd numrul de versiune 0.8. La sfrsitul aceluiai
an celor doi li se alatur i Ivar Jacobson.
In iunie 1996 apare versiunea 0.9, urmat la scurt timp, octombrie 1996, de apariia
versiunii 0.91. Versiunea 0.9 aduce i schimbarea denumirii din Metoda unificat
(Unified Method) n Limbajul unificat de modelare (Unified Modeling Language).
Cooptarea lui Jacobson n echip se concretizeaz printre altele n detalierea conceptului
de cazuri de utilizare (use case) i prezentarea unei descrieri mai amnunite pentru
diagramele cazurilor de utilizare. Conceptul de stereotip este mai bine explicitat, se
modific denumirile unor diagrame.
La 11 ianuarie 1997 este prezentat versiunea 1.0 care, nsoit de o documentaie mult
mai detaliat dect versiunile precedente, este trimis ctre OMG pentru standardizare.
1 septembrie 1997, a reprezentat un alt moment deosebit de important. Rational i alte
firme care spijina UML, printre care i doi fosti competitori, IBM/ObjectTime i
Taskon/Reich, a propus OMG o nou versiune 1.1. Noutatea semnificativ pentru aceast
versiune o reprezint introducerea limbajului OCL, un limbaj folosit pentru descrierea
regulilor de corectitudine ale metamodelului UML.
La 17 noiembrie 1997, OMG a anuntat adoptarea specificaiei UML ca limbaj standard
de modelare.
Schimbarea denumirii din Metoda Unificat n Limbaj de Modelare Unificat a fost justificat
prin:

reaciile primite din partea utilizatorilor care au sugerat c este mult mai important s se
acorde o atenie sporit conceptelor utilizate n dezvoltarea aplicaiilor. Recomandrile
referitoare la desfurarea etapelor de realizare i nlntuirea lor au fost lsate n planul
secund, faptul c eforturile de unificare au fost concentrate asupra limbajului grafic de
modelare, asupra semanticii lui i abia dup aceea asupra modului de utilizare a
conceptelor,

UML a fost conceput ca un limbaj universal care s fie utilizat la modelarea sistemelor
(indiferent de tipul i scopul pentru care au fost construite), la fel cum limbajele de
programare sunt folosite n diverse domenii.

Sublinierea aspectelor de limbaj nu semnific nicidecum ignorarea modului de folosire a lor.

UML presupune c metodologia este ghidat de cazurile de utilizare, c ea se bazeaz pe
arhitectura sistemului, iar procesul de aplicare a metodologiei este iterativ i incremental.
Detaliile acestui proces trebuie adaptate la domeniul aplicaiei, la modul de organizare al
echipei de realizatori, la experiena echipei. UML nu trateaz aspecte de metodologie, permitnd
astfel separarea limbajului de modelare de procesul aplicrii metodologiei.
1.2. Principalele pri ale UML
Principalele parti ale UML sunt:

Vederile (View) surprind aspecte particulare ale sistemului de modelat. Un view este o
abstractizare a sistemului, iar pentru construirea lui se folosesc un numr de diagrame.
Diagramele sunt grafuri care descriu coninutul unui view. UML are nou tipuri de
diagrame, care pot fi combinate pentru a forma toate view-urile sistemului.
Elementele de modelare sunt conceptele folosite n diagrame care au coresponden n
programarea orientat-obiect, cum ar fi: clase, obiecte, mesaje i relaii ntre acestea:
asocierea, dependena, generalizarea. Un element de modelare poate fi folosit n mai
multe diagrame diferite i va avea acelai nteles i acelai mod de reprezentare.
Mecanismele generale permit introducerea de comentarii i alte informaii despre un
anumit element.

1.2.1 View-uri
Modelarea unui sistem poate fi o munc foarte dificil. Ideal ar fi ca pentru descrierea sistemului
s se foloseasc un singur graf, ns de cele mai multe ori acesta nu poate s surprind toate
informaiile necesare descrierii sistemului. Un sistem poate fi descris lund n considerare
diferite aspecte:

Funcional: este descris structura static i comportamentul dinamic al sistemului;

Non-funcional: necesarul de timp pentru dezvoltarea sistemului
Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod;

Aadar pentru descrierea unui sistem sunt necesare un numr de view-uri, fiecare
reprezentnd o proiecie a descrierii intregului sistem i care reflect un anumuit aspect al sau.
Fiecare view este descris folosind un numr de diagrame care conin informaii relative a un
anumit aspect particular al sistemului. Aceste view-uri se acoper unele pe altele, deci este
posibil ca o anumit diagram s fac parte din mai multe view-uri.

View-ul cazurilor de utilizare (Use-case View)

Acest view surprinde funcionalitatea sistemului, aa cum este ea perceput de actorii externi
care interacioneaz cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme. n componena
lui intr diagrame ale cazurilor de utilizare i ocazional, diagrame de activitate. Cei interesai de
acest view sunt deopotriv clienii, designerii, dezvoltatorii dar i cei care vor realiza testarea i
validarea sistemului.
View-ul logic (Logic View)
Spre deosebire de view-ul cazurilor de utilizare, un view logic privete nuntrul sistemului
i descrie att structura intern a acestuia (clase, obiecte i relaii) ct i colaborrile care apar
cnd obiectele trimit unul altuia mesaje pentru a realiza funcionalitatea dorit.
Structura static este descris n diagrame de clas, n timp ce pentru modelarea dinamicii
sistemului se vor folosi diagramele de stare, de secvent, de colaborare sau de activitate. Prin
urmare, cei care sunt interesai de acest tip de vizualizare a sistemului sunt designerii i
dezvoltatorii.
View-ul componentelor (Component View)
Componentele sunt module de cod de diferite tipuri. n funcie de coninutul lor acestea pot
fi: componente care conin cod surs, componente binare sau excutabile.
View-ul componentelor are rolul de a descrie componentele implementate de sistem i
dependenele ce exist ntre ele, precum i resursele alocate acestora i eventual alte informaii
administrative, cum ar fi de exemplu un desfaurtor al muncii de dezvoltare. Este folosit n
special de dezvoltatorii sistemului, iar n componena sa intr diagrame ale componentelor.
View-ul de concuren (Concurent View)
Sistemul poate fi construit astfel nct s ruleze pe mai multe procesoare. Acest aspect, care
este unul nonfuncional, este util pentru o gestionare eficient a resurselor, execuii paralele i
tratri asincrone ale unor evenimente din sistem, precum i pentru rezolvarea unor probleme
legate de comunicarea i sincronizarea theadu-urilor.
Cei care sunt interesai de o astfel de vizualizare a sistemului sunt dezvoltatorii i integratorii
de sistem, iar pentru construirea lui se folosesc diagrame dinamice (stare, secvent, colaborare i
activitate) i diagrame de implementare (ale componentelor sau de desfurare).
View-ul de desfsurare (Deployment View)
Desfurarea fizic a sistemului, ce calculatoare i ce device-uri (numite i noduri) vor fi
folosite pentru realizarea efectiv a implementrii, cum sunt acestea conectate, precum i ce
4

componente se vor executa pe fiecare nod (de exemplu ce program sau obiect este executat pe
fiecare calculator), toate sunt surprinse n view-ul de desfurare.
Aceast tip de vizualizare a sistemului prezint interes sunt dezvoltatori, integratorii de sistem
i cei care realizeaz testarea sistemului, iar pentru construirea view-ului este folosit diagrama
de desfurare.
1.2.2 Diagrame
Diagramele sunt grafuri care prezint simboluri ale elementelor de modelare (model
element) aranjate astfel nct s ilustreze o anumit parte sau un anumit aspect al sistemului. Un
model are de obicei mai multe diagrame de acelai tip. O diagram este o parte a unui view
specific, dar exist posibilitatea ca o diagram s fac parte din mai multe view-uri, n funcie
de coninutul ei. n UML sunt nou tipuri de diagrame pe care le vom prezenta n cele ce
urmeaz.
Diagrama cazurilor de utilizare (Use Case Diagram)
Un caz de utilizare este o descriere a unei funcionaliti (o utilizare specific a sistemului) pe
care o ofer sistemul. Diagrama prezint actorii externi i cazurile de utilizare identificate,
numai din punctul de vedere al actorilor (care este comportamentul sistemului, aa cum este el
perceput de utilizatorii lui?) nu i din interior, precum i conexiunile identificate ntre actori i
cazurile de utilizare. Un exemplu de diagram a cazurilor de utilizare este prezentat n figura 2.

Diagrama claselor (Class Diagram)

O diagram a claselor prezint structura fizic a claselor identificate n sistem. Clasele
reprezint lucruri gestionate de sistem; clasele pot fi legate n mai multe moduri: associate
(conectate ntre ele), dependente (o clasa depinde/folosete o alt clas), specializate (o clas
este specializarea altei clase) sau mpachetate (grupate mpreun n cadrul unei unitai). Toate
aceste relaii se materializeaz n structura intern a claselor n atribute i operaii.
Diagrama este considerat static, n sensul c este valid n orice moment din ciclul de
via al sistemului. Un exemplu de diagram a claselor este prezentat n figura 3.

Diagrama obiectelor (Object Diagram)

Acest tip de diagram este un variant al diagramei claselor care n locul unei clase prezint
mai multe instane ale ei. Diagrama obiectelor folosete aproape aceleai notaii ca i diagrama
claselor cu dou mici diferene: obiectele sunt scrise subliniat i sunt vizualizate toate instantele
relaiei (vezi figura 4).
Dei nu este la fel de important ca diagrama claselor, cea o obiectelor este folosit pentru
exemplificarea unei diagrame a claselor de complexitate mare, permind vizualizari ale
instanelor actuale i a relaiilor exact aa cum sunt ele realizate. Mai poate fi folosit ca o parte
a diagramelor de colaborare, n care sunt vizualizate colaborrile dinamice existente n cadrul
unui set de obiecte.

Diagrama de stare (State Diagram)

O stare este de obicei un complement al descrierii unei clase. O diagram de stare prezint toate
strile prin care trece un obiect al clasei precum i evenimentele care-i cauzeaz modificrile
de stare. Modificarea strii se numete tranziie. Un exemplu de diagram de stare este
prezentat n figura 5.

Nu vom construi diagrame de stare pentru toate clasele din sistem ci numai pentru acelea
care au un numr de stri bine definit iar comportamentul clasei este afectat i modificat de
acestea.
Diagrama de secven (Sequence Diagram)
O diagram de secven prezint colaborarea dinamic ntre un numr de obiecte (vezi
figura 6), mai precis secvenele de mesaje trimise ntre acestea pe msura scurgerii timpului.
Obiectele sunt vzute ca linii verticale distribuite pe orizontal, iar timpul estereprezentat pe
axa vertical de sus n jos. Mesajele sunt reprezentate prin sgei ntre linile verticale ce
corespund obiectelor implicate n mesaj.

Diagrama de colaborare (Collaboration Diagram)

Aceast diagram surprinde colaborarea dinamic ntre obiecte, ntr-o manier similar cu a
diagramei de secven, dar pe lng schimbul de mesaje (numit i interaciune) prezint
obiectele i relaiile dintre ele (cteodat referite ca i context).
Cum decidem ce tip de diagram s folosim? Dac cel mai important aspect este timpul sau
secvena de mesaje vom folosi diagrama de secven, dar dac trebuie scos n evident
contextul, vom apela la o diagram de colaborare.
Desenarea unei diagrame de colaborare se face similar cu a unei diagrame a obiectelor.
Mesajele vor fi reprezentate prin sgei ntre obiectele implicate n mesaj i pot fi nsoite de
etichete care specific ordinea n care acestea vor fi transmise. De asemenea se pot vizualiza
condiii, iteraii, valori returnate, precum i obiectele active care se execut concurent cu alte
obiecte active (vezi figura 7).

Diagrama de activitate (Activity Diagram)

O diagram de activitate prezint fluxul secvenelor de activitai, ca n figura 8, i este de
obicei folosit pentru a descrie activitaile realizate n cadrul unei operaii, folosind dac este
cazul decizii i condiii.
Diagrama conine stri de aciune (action states), i mesaje care vor fi trimise sau recepionate
ca parte a aciunii realizate.

Diagrama componentelor (Component Diagram)

O diagram a componentelor prezint structura fizic a codului n termenii componentelor de
cod, realiznd o mapare de la view-ul logic la view-ul componentelor. O component poate s
conin un cod surs sau poate s fie ntr-o forma binar sau executabil. n cadrul diagramei
vor fi ilustrate i dependenele dintre componente, ceea ce permite o vizualizare simpl a
componentelor care vor fi afectate de modificarea uneia dintre ele.

Diagrama de desfurare (Deployment View)

Arhitectura fizic pe care va fi implementat sistemul, calculatoarele, device-urile (referite ca
nodurile sistemului), mpreun cu conexiunile dintre ele, vor putea fi prezentate n cadrul unei
diagrame de desfaurare. Componentele i obiectele executabile sunt alocate n interiorul
nodurilor, ceea ce ne va permite o vizualizare a unitailor care se vor executa pe fiecare nod.

10

2.Mersul lucrrii
2.1. Elaborarea Diagramelor USE-CASE
Diagrama cazurilor de utilizare reprezint un model iniial conceptual al unui sistem n procesul
de proiectare i exploatare.
Esena acestei diagrame const n faptul c: sistemul proiectat se reprezint ca o colecie de
entiti i actori care colaboreaz cu sistemul cu ajutorul aa numitor cazuri de utilizare.

Fig.1 Diagrama de utilizare a persoanei care poate fi administrator sau utilizator

n aceast diagram se poate observa posibilitile unui utilizator dac acceseaz bara de meniu
din partea de jos a programului.Sunt doar cteva posibiliti,pentru c softul ne permite accesarea
mai multor meniuri.

Fig.2 Diagrama de utilizare user-system

11

Aceast diagram reprezint posibilitatile si actiunile unui user in sistemul mail.

Fig.3 Diagrama de utilizare a Inregistrarii

Diagrama de mai sus ne arata ce include in sine operatia de inregistrare ca mail client. Ceea ce
este marcat cu include sunt cimpuri obligatorii de indeplinit, ceea ce este cu extend este o
optiune suplimentara care poate sa ramina neindeplinita ce ramine la discretia clientului user.

Fig.4-Diagrama de utilizare a unui admin

Un administrator are mai multe privilegii acesta are controlul absolut asupra siteului. Acesta la
fel trebuie sa aiba propria parola ca administrator, pentru a gestiona sistemul mail.
12

2.2.Elaborarea diagramelor de secven

Fig.5-Prima diagrama de secventa care defines interactiunea userului cu sistemul

n aceasta figura de mai sus este reprezentat schematic interaciunea utilizatorului cu sistenul
dinafara acestuia. Sunt artate pricipalele posibilitati a unui utilizator in sistemul mail.

13

Fig.6-Posibilitatile unui administrator

In figura 6 am reprezentat interaciunea administratorului cu sistemul si posibilitatile acestuia.
Funciile i aciunile acestuia asupra sistemului.

14

Fig.7-Diagrama care reprezinta interactiunea unei persoane cu sistemul

Diagrama n cauza reprezinta aciunile efectuate de o persoan n cauza crerii unui acount pe
mail. Sunt descrise in detalie fiecare aciune ndeplinit de acesta. Sunt ac iuni simple care fiind
efectuate pas cu pas in final este creat pagina de mail.
2.3.Elaborearea diagramelor de colaborare
Diagrama de colaborare de nivel de specificare reprezint rolurile elementelor (nivel de clase) ce
particip la colaborare. La nivel de exemple sunt reprezentate doar obiectele care au legtur cu
realizarea operaiilor.
Am elaborat 2 diagrame la nivet de exemple (figura 1 i figura 2) i 2 diagrame de colaborare la
nivel de specificare(figura 3 i figura 4)

15

Fig.2-Diagrama de colaborare la nivel de exemple interactiunea adminului cu sistemul

n diagram de mai sus este modelat un caz unde administratorul indeplinete careva ac iuni
asupra site-ului pe care l administreaz de la logare pina la ieire. Sunt reprezentate o mul ime
de relatii i interaciuni ce contin mesaje ntre obiectele acestui system.

Fig.1-Diagrama de colaborare la nivel de exemple interactiunea persoanei cu sistemul

n aceasta diagram este reprezetat interaciunea a unei persoane cu sistemul mail n care se
specifica fiecare pas efectuat de aceasta, acesta este miniatura diagramei de segven . Aici se
specific ce pai trebuie s ntreprind o persoana o binuit pentru a crea un cont nou de e-mail.

Fig.3-Diagrama de colaborare la nivel de specificare colaborarea ntre mail admin i userPJ

16

n figura de mai sus este reprezentat o diagrama de colaborare la nivel de specificare n care
este analizat sistemul de relaii dintre mail administrator i un utilizator simplu care este
Persoana Juridic. Relaia dintre acetia este aceea ca oricare din ei poate redactaa profilul su.

Fig.4-Diagrama de colaborare la nivel de specificare relaia ntre mail admin i userPF

La fel ca n diagrama percedent este reprezentat deja relaia administratorul mail client cu
utilizatorul Persoan Juridic prin aceea ca ambii au optiunea de a modifica ceva pe site.
2.4.Elaborarea diagramelor de clase
Folosirea diagramelor de clase:
1) n modelarea conceptual (analiza orientat obiect)
-

Clasele corespund conceptelor / obiectelor (entitilor) din domeniul aplicaiei ;

Nu exist neaparat o legatur direct cu clasele de obiecte utilizate n implementare i deci

diagrama de clase nu face parte din modelul structural al sistemului;
-

De regul, nu sunt definite operaiile din clase prin tipurile parametrilor i nici tipul
atributelor;

Diagrama de clase poate fi folosit n modelarea conceptual a unei baze de date. n modelul
fizic al BD clasele se implementeaza prin tabele ale bazei de date.

Pentru specificarea software

Se pune accent pe interfa i nu pe implementare;

Adesea se folosete cuvntul tip n legatura cu interfaa unei clase: un tip poate fi
implementat de mai multe clase i o clasa poate implementa mai multe tipuri.

In proiectarea de detaliu si implementare

Diagramele conin clase de obiecte ntr-un anumit limbaj de programare;

Diagramele fac parte din modelul structural al sistemului.

17

Fig.1-Diagrama de clase generala

n diagrama de clase reprezentat n figura 1 este adus un exemplu ce componente aree-mailul i
a cui component este acesta. Acesta are clieni care pot fi useri sau administartori care la rindul
sau pot fi persoane fizice sau persoane juridice. Ca s fie clien i mail ace tia ndeplinesc o fi
de nregistrare, care la rindul su este vizualizat cu ajutorul browserului prin interfa.

Fig.2-Structura serverului e-mail

18

n figura 2 este reprezentat structura serverului mail n care sunt cteva clase abstracte (MTA i
MDA).Partea cea mai important a serverului mail este MTA (eng. Mail Transfer Agent- agent
mail transef) a crui sarcin este de a trimite i primi e-mail. MTA lucreaza dupa protocolul
SMTP, i el singur, este suficient n principiu de a crea sistemul potei electronice. MTA primind
scrisoarea, o pune in cutia postal a utilizartorului pe server, la care acesta trebuie sa primeasc
acces. De aici le intercepteaz MDA (Mail Delivery Agent agent de livrare e-mail) sarcina lui
este ca la cererea clientului e-mail s i transmita pota din cutia potal pe server. MDA lucreaza
dupa protocolul POP3 sau poate sa lucreze i dup IMAP.
MDA nu are nici o atribuie la procesul de transmitere a potei. Aceasta este prerogativa MTA.
Poate fi fcuta o analogie, MTA poate fi vzut ca un oficiu potal care se ocupa cu primirea i
transmiterea potei, iar MDA ca pota care duce corespondena acas. Dac potaul se
imbolnvete asta nu se rfrnge asupra lucrului potei. La fel precum cedarea MDA nu duce la
defctiunea serverului mail.

Fig.3- Structura i principiul de funcionare a serverului e-mail

n diagrama din figura 3 sunt utilizate 2 protocoale SMTP i POP3. SMTP(eng. Simple mail
transfer protocol- protocol simplu de tranfer e-mail) acesta este un protocol de reea pe larg
utilizat proiectat pentru transmiterea potei electronice in reeaua TCP/IP. Iar POP3(eng. Post
Office Protocol Version 3- protocolul oficiului potal) este internet-protocol standart utilizat de
clienii potei electronice pentru primirea corespondenei de pe un server de la distan pe
legtura TCP/IP, este cel mai rspndit protocol pentru extragerea potei. Protocolul POP a fost
dezvoltat n cteva versiuni, standardul de astzi este versiunea a treia (POP3). Majoritatea din

19

furnizorii de servicii mail (precum Hotmail, Gmail i Yahoo! Mail) de asemenea sus in IMAP i
POP3.
Examinm cazul expedierii unui e-mail. n cazul dat user1 care se afl n domenul example.org
(user1@example.org) i scrie lui user4 care se afl n domenul example.com
(user4@example.com). Pentru user1 procesul de trimitere a scrisorii const din redactarea
scrisorii i apsarea butonului Trimite n clientul de e-mail. Clientul de e-mail se conecteaz cu
MTA dup protocolul SMTP i n primul rind raporteaz scrisorile sale de acreditare. Autoriznd
utilizatorul, MTA primete scrisoarea i ncearc s o trimit mai departe.
Autorizarea nu este o procedura obligatorie pentru MTA, dar fr ea vom primi releu deschis,
adic oricine poate s se foloseasc de serverul nostru pentru a redireciona pota. n timpul de
fa releuri deschise apar de la aceea c serverul este gresit setat.
Pentru autorizare MTA poate folosi lista proprie de utilizatori, lista de system, listele
utilizatorilor LDAP sau AD. La fel mai este o posibilitate autorizarea POP inaintea SMTP, cnd
utilizatorul nainte de a trimite mesajul se autorizeaz pe MDA,care, la rndul su confirm
autentificarea utilizatorului pentru MTA.
La urmtorul pas MTA analizeaz scrisoarea de informative de serviciu, determinnd domenul
destinatarului, dac el se regasete printer cele deservite de MTA, se cauta destinatarul i scrisoare
se pune n cutia potal. Aceasta ar fi avut loc daca user1 scria cu domenul example.org.
Dac domenul destinatarului nu este deservit de MTA, se formeaz o cerere DNS, care cere
inscrierile MX pentru domenul dat. nregistrarile MX reprezint un tip special al DNSinregistrri, care conine numele serverelor e-mail, care prelucreaza corespondena care
vinepentru domenul dat. MX-nregistrri pot fi cteva, n aces caz MTA ncearc pe rnd s fac
legatura, ncepnd cu serverul care are cea mai mare prioritate. n lipsa MX-nregistrrilor se
solicit A-inregistrari (inregistrrile de adres, asociat numelui de domen cu dresa IP ) i se
ncearc trimiterea corespondenei la hostul indicat. Dac trimiterea nu este posibil, ea se
intoarce inapoi la expeditor cu mesajul de eroare.

2.5.Elaborarea diagramelor de stare

20

Diagramele efectuate pentru aceast lucrare de laborator:

Fig.1-Verificarea unui mesaj i strile n care se poate afla

n diagrama de mai sus este deschis prin ce stari trece o scrisoare pn ce ea este trimis. Pentru a
scri un mesaj sau o scrisoare mai inti este necasar ca utilizatorul (autorul scrisorii) trebuie s i
acceseze acountul de mail. Apoi s redacteze mesajul, acesta este analizat dup coninut i n
dependen de rezultat mesajul trece n starea urmatoare. De exemplu dac coninitul nu conine
elemente interzise acesta trece n starea verificat i apoi n starea trimis.

21

Fig.2-Diagrama de stare a unui mesaj n trimitere

n aceast diagrama se stri care este reprezentat n figura de mai sus arata n ce stri se poate
afla e-mailul atunci cnd acesta este trimis. Pentru a fi trimis acesta trebuie n primul rind s fie
redactat, i apoi este trimis n acelai timp este salvat. Aflndu-se n starea trimis acesta poate
parcurge 2 ci pentru a ajunge la destinatar, poate fi direct primita de ctre acesta sau n caz c
este un utilizator extern adica din alt domen acesta trece prin gateway (hardware sau software
Router pentru interfaare de retele de calculatoare care folosesc protocoale diferite) n starea de
tranzit (mesajul este n tranzit atunci cnd a prsit sistemul mesager pentru un destinatar
extern) apoi ajunge la destinatar. Fiind livrat acesta poate trece n starea citit. Din starea salvat
poate trece n starea ters prin tergere i invers prin restabilire sau poate fi arhivat.

22

Fig.3-Diagrama de stare a unui mesar primit

n figura 3 este reprezentat diagrama de stare a unui mesaj primit. Fiind primit mesajul este
verificat coninutul acestuia la cuvinte necenzurate, spam sau publicitate. Dac acesta conine
careva elemente interzise este trecuta in starea spam. n caz contrar acesta este admis i poate
trece n starea citit. De aici acesta poate fi salvat sau ters.

23

2.6.Elaborarea diagramelor de activiti

Diagramele create sunt urmtoarele:

Fig.1-Diagrama de activitate crearea cont mail

n diagrama de mai sus clentul e-mail decide in ce domen s i creeze contul de e-mail. El va lua
decizia n dependen n ce ar triete, dar pentru aceasta are nevoie de browser i de conexiune
la rea n caz c conectarea la reea lipsete acesta va cerca mai trziu.

Fig.2- Diagrama de activitate pentru crearea i trimiterea unui e-mail

24

n figura 2 este reprezentat diagrama de activitate n cazul crerii i trimiterii unui e-mail.Pentru
a crea un e-mail utilizatoeul este nevoit ca s se autentifice pe contul su de e-mail. Atunci cnd
acesta nu sa autentificat este rugat printr-o notificare ca s se autentifice, n caz c acesta sa
autentificat va ncepe prin apsarea butonului scriei, apoi acesta va introduce coninutul
scrisorii, ataeaz fiier i trimite scrisoarea ctre destinatar. n caz ca a fost cu succes trimiterea
mesajului se va afia o notificare precum c mesajul a fost trimis, iar dac a fost careva eroare de
trimitere acesta va fi nevoit s mai ncerce o data.

Fig.3- Diagrama de activitate pentru cautarea i afisarea unui client

n figura 3 este reprezentat diagrama de activitate pentru cutarea i afiarea unui client din
baza de date. Administartorul e-mail-lui are nevoie de un anumit client pe care l caut n baza de
date pe care o are la dispozitie, dac acesta nu a fost gasitn baza de date acesta se adaug i apoi
se afieaz. n caz c acesta exist deja n baza de date se afi eaz. Atunci cnd aceasta nu avut
loc se pune ntrebarea sau cazul de decizie dac s se actualizeze baza de date sau nu. Dupa
actualizare se mai incearc o data afiarea clientului.

25

2.7.Elaborarea diagramelor de componente i de desfurare

Fig.1- Diagrama de componente/ desfurare

Diagrama de mai sus prezint legtura dintre componentele a careva noduri. Adic baza de date
este dependent de numrul de clieni i de funcionarea e-mail-ui, acesta la rndul su realizeaz
interfaa cu utilizatorl care depinde de browserul folosit. E-mailul are un fiier jurnal dependent
de acesta care nregistreaz oricare schimbare sau aciune ndeplinit de utilizatori sau
administratori. Utilizatorul pentru a accesa e-mailul are nevoie de un browser.

26

Fig.2-Diagrama de desfurare a unui server e-mail

n figura 2 este rerezentat diagrama de desfaurare n care se descrie accesul la server e-mail pe
nivele. Nivelul cel mai de jos reprezinta dispozitivele cu ajutorul carora se introduce infosrma ia
la nivelul 2 care reprezint nite procesoare care au capacitatea de calcul, cum ar fi PC, telefon
mobil sau tableta prin care pot fi conectate la un web server ca i extrage/introduce informa ia de
pe serverul e-mail.

27

Concluzie:
n aceast lucrare am studiat tipurile de diagrame din limbajul UML, am elaborat aceste
diagrame la tema Analiza i proectarea unui sistem mail client. Pentru a ndeplini aceast
sarcina am utilizat instrumentul Enterprise Architect, cu acesta m-am acomodat foarte repede,
este uor de lucrat cu acesta deoarece este foarte bine conceput i are multe funcionaliti pentru
realizarea oricrei diagrame.
n realizarea sarcinii propuse m-a ajutat foarte mult conspectul de la cursul de AMSI, nsa am
utilizat i surese adiionale cum ar fi tutoriale (pentru cunoaterea instrumentului i realizarea
ctorva diagrame ), literatura adugtoare.
Nu am ntlnit mari greuti la realizarea diagramelor deoarece de la bun nceput mia placut
acest limbaj, este un libbaj care utilizeaz elemente grafice i este foarte uor de n eles cu ce
scop i cum se utilizeaz.
Realizarea acestei lucrri a consumat destul de mult timp deoarece au fost create destul de
multe diagrame i fiecare a necesitat timp pentru cercetare sistemului, analiz i creare. Am aflat
multe lucruri noi despere sistemul mail, adica care sunt principiile de functionare a acestuia.

28

Bibliografie
http://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in%20UML.pdf
https://www.youtube.com/watch?v=M02hWVPvR_Y

29