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................................................................................62.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 .........27Concluzie ...........................................................................................29Bibliografie.........................................................................................30

Introducere n UML1.1. Aparitie si evolutieUML 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 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.

2.Mersul lucrrii2.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-systemAceast 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.

2.2.Elaborarea diagramelor de secven

Fig.5-Prima diagrama de secventa care defines interactiunea userului cu sistemuln aceasta figura de mai sus este reprezentat schematic interaciunea utilizatorului cu sistenul dinafara acestuia. Sunt artate pricipalele posibilitati a unui utilizator in sistemul mail.

Fig.6-Posibilitatile unui administratorIn figura 6 am reprezentat interaciunea administratorului cu sistemul si posibilitatile acestuia. Funciile i aciunile acestuia asupra sistemului.

Fig.7-Diagrama care reprezinta interactiunea unei persoane cu sistemulDiagrama 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 aciuni simple care fiind efectuate pas cu pas in final este creat pagina de mail. 2.3.Elaborearea diagramelor de colaborareDiagrama 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)

Fig.2-Diagrama de colaborare la nivel de exemple interactiunea adminului cu sistemuln diagram de mai sus este modelat un caz unde administratorul indeplinete careva aciuni asupra site-ului pe care l administreaz de la logare pina la ieire. Sunt reprezentate o mulime de relatii i interaciuni ce contin mesaje ntre obiectele acestui system.

Fig.1-Diagrama de colaborare la nivel de exemple interactiunea persoanei cu sistemuln 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 userPJn 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 userPFLa 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 claseFolosirea 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.1. 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.1. 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.

Fig.1-Diagrama de clase generalan 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 clieni mail acetia ndeplinesc o fi de nregistrare, care la rindul su este vizualizat cu ajutorul browserului prin interfa.

Fig.2-Structura serverului e-mailn 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-mailn 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 furnizorii de servicii mail (precum Hotmail, Gmail i Yahoo! Mail) de asemenea susin 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 DNS-inregistrri, 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 stareDiagramele efectuate pentru aceast lucrare de laborator:

Fig.1-Verificarea unui mesaj i strile n care se poate aflan 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.

Fig.2-Diagrama de stare a unui mesaj n trimiteren 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.

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.

2.6.Elaborarea diagramelor de activitiDiagramele 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

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

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.

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 infosrmaia 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 informaia de pe serverul e-mail.

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

Bibliografiehttp://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in%20UML.pdfhttps://www.youtube.com/watch?v=M02hWVPvR_Y29