Escolar Documentos
Profissional Documentos
Cultura Documentos
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
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.
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:
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.
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.
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.
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.
13
14
15
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.
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.
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.
17
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.
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.
21
22
23
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.
25
26
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