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
([email protected]) i scrie lui user4 care se afl n domenul
example.com ([email protected]). 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